Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Tue Apr 12 2005 05:11 am

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?

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

    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.

.