> Will it be possible to issue only compiler ordering barrier (release,
> acquire or full), but not hardware ordering barrier in C++0x?
>
> Accesses to volatile variables are ordered only with respect to
> accesses to other volatile variables. What I want it to order access
> to variable with respect to accesses to all other volatile and non-
> volatile variables (w/o any hardware barriers, only compiler
> ordering).
>
> Now it can be accomplished with "__asm__ __volatile__
> ("" : : :"memory")" on gcc, and with _ReadWriteBarrier() on msvc. I am
> interested whether it will be possible to do this in C++0x language w/
> o compiler dependency.
>
> Such compiler barriers are useful in effective synchronization
> algorithms like SMR+RCU:http://sourceforge.net/project/showfiles.php?group_id=127837
> (fastsmr package)
> because they allows one to eliminate all hardware memory barriers from
> fast-path. ...

> Will it be possible to issue only compiler ordering barrier (release,
> acquire or full), but not hardware ordering barrier in C++0x?
>
> Accesses to volatile variables are ordered only with respect to
> accesses to other volatile variables. What I want it to order access
> to variable with respect to accesses to all other volatile and non-
> volatile variables (w/o any hardware barriers, only compiler
> ordering).

> [...]
> All accesses to shared data MUST be synchronized with atomics: [...]

> On May 2, 12:43 pm, Anthony Williams yahoo.com> wrote:

>> [...]
>> All accesses to shared data MUST be synchronized with atomics: [...]

>
> Can you elaborate this point please. How can you generally synchronise
> N processes with help of atomics? Do you mean only two processes under
> certain circumstances?

> Dmitriy Vyukov gmail.com> writes:

>> Will it be possible to issue only compiler ordering barrier (release,
>> acquire or full), but not hardware ordering barrier in C++0x?

>

>> Accesses to volatile variables are ordered only with respect to
>> accesses to other volatile variables. What I want it to order access
>> to variable with respect to accesses to all other volatile and non-
>> volatile variables (w/o any hardware barriers, only compiler
>> ordering).

>
> Within a single thread, all operations *are* ordered. The ordering relations
> are happens-before and sequenced-before. A is sequenced-before before B when
> A physically comes before B in the source code, or the sequencing rules say so
> (e.g. lhs of a comma op is sequenced before rhs).
>
> If A is sequenced-before B, then A also happens-before B. If you then
> introduce a synchronization edge between thread T1 and thread T2
> (e.g. store(mem_order_release) on T1, load(mem_order_acquire) on T2), then
> anything that happens-before the store also happens-before the load. ...

> On 2 май, 14:43, Anthony Williams yahoo.com> wrote:
> I can prove that I have happens-before relation if I can enforce
> correct compiler ordering. Consider following code:
>
> std...

> I can prove that I have happens-before relation if I can enforce
> correct compiler ordering. Consider following code:
>
> std::vector g_nonatomic_user_data;
> std::atomic_int g_atomic1;
> std::atomic_int g_atomic2;
>
> std::vector thread()
> {
> g_atomic1.store(1, std::memory_order_relaxed);
> // compiler store-load fence
> if (g_atomic2.load(std::memory_order_relaxed))

> Szabolcs Ferenczi gmail.com> writes:

>> On May 2, 12:43 pm, Anthony Williams yahoo.com> wrote:

>>> [...]
>>> All accesses to shared data MUST be synchronized with atomics: [...]

>

>> Can you elaborate this point please. How can you generally synchronise
>> N processes with help of atomics? Do you mean only two processes under
>> certain circumstances?

>
> If any thread modifies shared data that is not of type atomic_xxx, the
> developer must ensure appropriate synchronization with any other thread that
> accesses that shared data in order to avoid a data race (and the undefined
> behaviour that comes with that).