Re: [boost] Re: Threads docs updated in CVS

From: James Dennett (jdennett_at_[hidden])
Date: 2001-08-13 20:01:48

Scott McCaskill wrote:

>>to be portable you have to serialize *all* your
>>writes/updates which should also preclude *any*
>>concurrent reads (unless you have read access only).
>>you should do it using portable synch. functions
>>such as mutex.lock, join, semaphore.wait, rwlocks,
>>etc.. *not* using any volatiles - it simply does
>>not help at all and could just hurt performance,
>>instead.
>>
>
>I know, I wasn't using volatile for that.  I thought that volatile had to do
>with forcing the value to be written to memory rather than stored in the
>processor's cache.  But then, I suppose there are all sorts of things that
>wouldn't work if it was possible for one processor to do a read and get a
>stale value from main memory.
>
True, all sorts of bad things can and do happen in such systems,
if programmers don't take care.  volatile doesn't help; the problems
arise even with volatile specified.

Suppose we have [volatile] sigatomic_t a,b; and two processors.
a, b are both initially 0.  Processor 1 writes 1 to a, then 1 to b.
Processor 2 may read the 1 in b and *then* read a 1 in a, if no
synchronization is used, on some systems.  I believe that SGI's
cc-numa memory architecture avoids this problem by handling
it in hardware, but other systems require code to call library
routines which insert explicit "memory barrier" type instructions.

These discussions pop up in comp.lang.c++.moderated once in
a while and are usually sent to comp.programming.threads,
where threads experts explain the weird and wonderful world
of "exotic" multi-processor systems.

--- James Dennett