- changed status to resolved
Fixup API ref for atomics
Current API ref for atomics include text like:
Precondition: T must be one of the approved atomic types. T must be the only type used by any in-flight atomic referencing p.
...
Performs an atomic read of the location p and returns its value in a future.
The preconditions should include that p points to an object of type T (eg p is not a null pointer, or pointing at unallocated/unaligned space).
Also, in the second sentence we should delete the word "in-flight" (and possibly copy this restriction to the overview). In particular, we don't support p being a pointer to member of a union that is sometimes accessed as uint64_t and sometimes as uint32_t. Atomic domains are permanently type-specific, not just during races.
Finally instead of "Performs ... of the location p" it should probably say "of the object at location p".
Comments (3)
-
Account Deleted -
reporter - changed status to open
New text:
T must be the only type used by any atomic referencing p for the entire lifetime
1971 of UPC++.I think there's still a minor ambiguity here. In particular, if the user has a type like (pseudocode for a shared-memory object declaration):
union { uint64_t full64; struct { uint32_t lo32; uint32_t hi32; }; } V;
If the user invokes atomics with p1==&V.full64 (and T=uint64_t), we need to clearly disallow atomics with p2==&V.hi32 (and T=uint32_t). Note in this case those are NOT the same value of p (p1 and p2 are different addresses in this case, although the referenced objects overlap).
Perhaps clarify with something like:
T must be the only type used by any atomic referencing any part of the object storage referenced by p for the entire lifetime of UPC++
-
Account Deleted - changed status to resolved
- Log in to comment