blob: e423f6b4045d51af956128520bae02fe7a839fab (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
shared qualifier
----------------
(just some ideas. subject to change)
Related to the "volatile" qualifier in C. It has the following semantics:
* inhibits implicit accesses to the data, generated by the compiler
(such a implicit copying)
* prevents optimization of accesses. reading or writing to it may not
be optimized out or reorganized. (but the code around it may be
re-organized, so a non-shared access could be re-ordered relative to
the shared access)
* reads and writes of types of up to machine word size will be atomic
(generally this applies to pointers and "count" types), except for
structs and unions.
access to bitfields are atomic only when reading the base type.
* no guarantees on ordering are made when multiple threads access
shared data, except that writes to a word-sized variable or
shared struct member by one thread will be seen in-order by another
thread. different threads may see different data.
* accessing only a part of the data is forbidden (i.e. accessing a
member of a struct of bitfield), unless that data is also marked
as shared.
* shared is not transitive through pointers, BUT having a pointer to
writable data in a shared struct is forbidden unless the pointer is
also marked as shared.
The "shared" qualifier is useful in the following cases:
* access to hardware that's mapped in memory.
* access to memory that's shared between threads or processes.
* access to memory that's shared with the OS kernel
(perhaps a timer value that's updated by the kernel).
|
