Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Alexander Terekhov
Date : Tue Apr 12 2005 07:54 pm


Peter Dimov wrote:
> 
> 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.

Would you please quote the relevant passage(s)?

> 
> >> 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.

Please elborate.

> 
> >>     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

PLn models say that "two operations conflict if they are to the same 
location and at least one of them is a write" and that "given a pair 
of conflicting operations u and v in an execution, operation u 
competes with operation v if and only if there is no ordering chain 
(as defined above) between u and v (either from u to v or vice versa). 
An operation u is a competing operation if and only if there exists 
at least one conflicting operation v in this execution that competes 
with u. Otherwise, the operation is a non-competing operation."

> "competing" - if there is a race.

And what I meant was that for loads, "competing" means that it can 
collide with other store. For stores, "competing" means that it can 
collide with other store, "non-competing" means that it can collide 
(and survive ;-) ) with other load (but not store), and "exclusive" 
means no collision at all. 

> 
> > 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? 

Well, neighboring ints can also be manupulated by one "wide" 
instruction (see the other case). Without atomic<>, that is. ;-)

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

It will fail to compile. atomic_pair<T> might work, though.

regards,
alexander.

.