blob: d7a714e45ca26bdeca1d0820608160c3fe26acd9 (
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
35
|
"var threaded ownref" is only safe if the pointer is "moved away" with an
atomic get-and-clear operation (for ?ownref) and get-and-swap
(for ownref and ?ownref).
- free() won't accept either of those due to the threaded keyword.
- Special get_and_set and get_and_clear functions will be needed for access
- Getting a non-own ref is not possible due to the exclusive access nature
(unless the area is locked, so the ref can be non-threaded)
"var threaded ref" can work, BUT when the ref is written it must have the
same lifetime as the previous ref that was there (alternatively, it can
have the same lifetime as the structure that contains the threaded ref).
- like "var threaded ownref", this also requires some kind of get_and_set
operation.
- "var threaded ?ref" can be assigned from a "none" value to an actual
reference only in accordance with the alternative condition.
"writeonly threaded ownref" is unsafe (unless we can be sure that the
ref is either "none" or uninitialized).
"writeonly threaded ref" is only safe according to the alternative
condition for "var threaded ref".
"threaded ownref" (read-only) is strange, since it would imply that another
thread has "var threaded ref" access. So the other side could only assign
refs that have the same lifetime as something else (i.e. something that
we own).
"threaded ref" (read-only) is tricky. It is safe if the target lifetime is
guaranteed to be as long as the ref itself. Otherwise it is unsafe.
The "aliased" keyword works like "threaded", but can use non-atomic
get-and-clear or get-and-set operations.
|
