Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Tue Apr 12 2005 01:54 pm

Alexander Terekhov wrote:
> Peter Dimov wrote:
>> Do you mean that on some systems a 32 bit int aligned on a 32 bit
>> boundary may not allow atomic accesses? Or in more general terms, a
>> type T's natural alignment may not be sufficient to ensure atomicity?
>
> Show me first chapter and verb for "natural alignment" in C/C++ or
> even POSIX, please.

Search for "alignment" in C++03. It doesn't specifically say "natural" 
because for the standard non-natural alignments do not exist and unaligned 
accesses are undefined.

>> volatiles? Who said anything about volatiles?
>
> Well, you said: "Why wrap the thing in its own atomic<> type (I'm
> reminded of volatiles here) instead of just providing labeled
> access functions?"

Reminded of Java volatiles... where I need to change the type of the 
variable in order to do atomic operations on it.

>>     T atomic_load_acq( T * pt );
>>     void atomic_store_rel( T * pt, T v );
>>     // et al
>>
>> and ordinary non-volatile loads and stores for non-competing
>> accesses... what am I missing? "naked_competing" loads? Add
>> atomic_load_nsync, then.
>
> First off, an access can be either atomic or not atomic. Non-competing
> load accesses need not be atomic. Non-competing store accesses must be
> atomic (because it is non-competing with respect to stores, but it is
> "competing" with respect to loads), exclusive store or load accesses
> need not be atomic.

Hmm, I must be missing something. When I say "non-competing" I mean 
"exclusive" in your terminology. The PLn models use the same definition for 
"competing" - if there is a race.

> Competing accesses may need msync to impose proper ordering.
>
> Now, as for your functions, consider:
>
>  char ab[2];
>
> Thread A:
>
>  atomic_store_rel( &ab[0] );
>  atomic_load_acq( &ab[1] );
>
> Thread B:
>
>  atomic_load_acq( &ab[0] );
>  atomic_store_rel( &ab[1] );
>
> How is this supposed to work on a processor that doesn't have atomic
> byte access instructions?

It isn't. It will fail to compile. The atomic_* family will work on int, 
long, T* and PODs with sizeof(int), sizeof(long), sizeof(T*) and maybe with 
2*sizeof(int) etc.

Why is atomic<char> useful? And how is atomic<p2> (where p2 is a struct of 
two pointers) supposed to work without DWCAS? Contain a spinlock?

.