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

Alexander Terekhov wrote:
> Peter Dimov wrote:
>> 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)?

3.8/1

"The lifetime of an object of type T begins when:
- storage with the proper alignment and size for type T is obtained, and
- if T is a class type with a non-trivial constructor (12.1), the 
constructor call has completed."

3.9/5

"Object types have alignment requirements (3.9.1, 3.9.2). The alignment of a 
complete object type is an implementation-defined integer value representing 
a number of bytes; an object is allocated at an address that meets the 
alignment requirements of its object type."

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

I meant that on a specific platform, some types can be read/written/updated 
atomically, and some cannot. But the requirement to "tag" objects that will 
participate in such operations, whether with "volatile", or with atomic<>, 
doesn't seem natural or necessary to me.

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

Right. I was using PLn terminology, where stores that compete with loads are 
"competing".

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

I don't think that such platforms are in widespread use (unless IA64 or 
x86-64 Windows compilers do 64 bit stores for ints... I doubt it), but if 
they do, atomics for ints won't be defined there. Such an int runs counter 
to the spirit of C, though. Stores on ints are not supposed to be carried 
out in "double precision", so to speak. Chars may do that, this is well 
known.

Anyway, I see your point. atomic<> can be useful.

.