Re: [boost] Boost.Threads - Questions

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-20 10:57:24

> From: "Alexander Terekhov" <terekhov_at_d...>
> > > [1] No atomic_t, why?
> >
> > http://groups.google.com/groups?as_umsgid=3AFA6932.4EADD8BB%40web.de
> > http://groups.google.com/groups?as_umsgid=3B016AF0.5E55E7A1%40web.de
>
> I think that on win32, Interlocked* is supposed to be safe on multiple
> processors.

it is documented to be safe with respect to corresponding atomic
operation(s) only. win sdk/Intrlocked stuff does not say anything
at all with respect to memory visibility/memory access ordering
on system with multiple processors and week/relaxed memory model,
such as e.g. IA64:

ftp://download.intel.com/design/IA-64/Downloads/24531802s.pdf

"13. MP Coherence and Synchronization..."

and i am really interested to see in which memory
ordering mode IA64 windows/MP version will actually
run (strong/IA32-compatible or week/IA64-native) since
win sdk does not cover MP memory visibility/ordering
issues, AFAIK. a lot of code will become broken on IA64
without extra memory synch. instruction(s) and/or
constrained (acquire/release) versions of load/store/
cmpxchg/..

> On platforms that don't have atomic primitives an atomic_t will
> simply be a (mutex, long) pair.

AFAIK all platforms have atomic primitives, MP-safe if applicable.
this is how mutexes/locks work. but please do not mix "atomicity"
and memory ordering.

> As it stands, to make shared_ptr thread safe, I have to roll my own
> atomic_t.

for windows/IA32 maybe.. however, consider that AFAICT IA64
version of ref.counter decrement function should use cmpxchg.rel
(but not cmpxchg.acq) instruction and on the other hand IA64
version of {spin}lock.acquire function should use cmpxchg.acq
(but not cmpxchg.rel) instruction. do you have any ideas
whether Interlocked*/IA64 really provide required memory
ordering semantics (basically bidirectional memory fence,
to be safe)? i do not..

regards,
alexander.