From 3eac8b91cfd37c27e75da5c7e21e394d10f97adf Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Thu, 22 Jul 2021 10:35:09 +0200 Subject: [PATCH] book/resources: highlight that `#[lock_free]` includes a compile-time check for the "same priority requirement"; this prevents data races --- book/en/src/by-example/resources.md | 1 + 1 file changed, 1 insertion(+) diff --git a/book/en/src/by-example/resources.md b/book/en/src/by-example/resources.md index 855cde93a6..4f6c3c317c 100644 --- a/book/en/src/by-example/resources.md +++ b/book/en/src/by-example/resources.md @@ -100,6 +100,7 @@ $ cargo run --example only-shared-access A critical section is *not* required to access a `#[shared]` resource that's only accessed by tasks running at the *same* priority. In this case, you can opt out of the `lock` API by adding the `#[lock_free]` field-level attribute to the resource declaration (see example below). Note that this is merely a convenience: if you do use the `lock` API, at runtime the framework will *not* produce a critical section. +Also worth noting: using `#[lock_free]` on resources shared by tasks running at different priorities will result in a *compile-time* error -- not using the `lock` API would be a data race in that case. ``` rust {{#include ../../../../examples/lock-free.rs}}