Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Alexander Terekhov
Date : Tue Apr 12 2005 11:37 am


Peter Dimov wrote:
> 
> Alexander Terekhov wrote:
> > Peter Dimov wrote:
> > [...]
> >> But on the other hand "int" offers "basic" thread safety by default
> >> and "strong" thread safety if I only touch it with atomic_load_acq
> >> and atomic_store_rel.
> >
> > Only if you properly isolate (align and pad if nessesary) it.
> >
> > That's one reason for atomic<> wrapper.
> 
> 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.

> 
> >> This is also why I'm not particularly fond of Alexander's atomic<>
> >> dedicated wrapper type. Providing atomic access via ordinary
> >> functions seems more natural.
> >
> > Another reason is to "enforce" proper labeling for all accesses by
> > making the type opaque. An exclusive access on atomic<int> doesn't
> > need to be isolated/atomic at all, it can be combined with other
> > accesses. How are you going to do it all with "extended-for-threads"
> > C/C++ volatiles (also mentioned by you in another message not here),
> > for example?
> 
> 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?"

> 
>     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. 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? Even if it has, consider

  char ab[2];

Thread A:

  a[0] = 1; 
  .
  .
  .
  atomic_load_acq( &ab[1] );

Thread B:

  atomic_store_rel( &ab[1] );

regards,
alexander.

.