book/resources: highlight that #[lock_free] includes a compile-time check

for the "same priority requirement"; this prevents data races
This commit is contained in:
Jorge Aparicio 2021-07-22 10:35:09 +02:00
parent c62fd967d7
commit 3eac8b91cf

View file

@ -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. 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). 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. 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 ``` rust
{{#include ../../../../examples/lock-free.rs}} {{#include ../../../../examples/lock-free.rs}}