Re: C++ Threads, what's the status quo?

On 2007-01-13, JohnQ <johnqREMOVETHISprogrammer@yahoo.com> wrote:


Yes, in a certain limited (and very useful!) set of cases. I'm not sure
what
you refer to with Volatile<T>, so I'll try to exemplify it more concretely.

Consider the following small program [it's useless, but enough to illustrate
concepts; there are many _useful_ examples where atomicty guarantee would
be nice].

int x;

void thread_i() {
   while(1) {
   // do something
   if(--x == 0)
     break;
   // do something else
}

Now, in the situation as it is now, the compiler may generate code for
'--x == 0' as [for those who know x86 ASM, I write it by the side]

   1. load x into register (movl x, %eax)
   2. decrement register (decl %eax)
   3. store register into x (movl %eax, x)
   4. if result == 0 goto exit (jz exit)

If you have several copies of thread_i, there is a race condition between
steps 1-3. Some architectures, like x86, offer atomic memory decrement.
*IF* the compiler could be forced to generate atomic operation for
'--x == 0', the generated code would look like:

   1. [decrement memory location x and set flags] (decl x)
   2. if the result was zero, goto exit (jz exit)

Now 1. is single atomic operation, where the hardware serializes parallel
accesses to memory. No race conditions are possible. Yes, wrapping x
into something Volatile<int> x _would_ work with the disadvantages that

   - implicit wrapping in a mutex is suboptimal if the architecture
     supports atomic operation
   - you have to use inline assembly to code optimized Volatile<int>
     that uses atomic instructions, because you currently have _no way_
    to force the compiler to any particular choice of instructions

If the variable were declared as 'atomic int x;' the compiler would be
obliged to generate the 2nd instruction sequence *OR* report an error
if the operation "--x == 0" is not supported by the target architecture.
Thus, you would not need locks for simple operations that are supported
by the target CPU. On x86, this includes all simple arithmetic and logic
operations. [the wonderful world of CISC :)]

My motive for proposing the atomic keyword is that someone mentioned
"objects" and bitfields and that C++ doesn't have a "memory model". In
my opinion, atomic access is a more fundamental concept than "memory model".
The example was whether it was safe to concurrently access x and y in
something like:

struct {
      [atomic] unsigned x:1;
   unsigned y:1;
} z;

On some architectures z.x = 1; cannot be executed atomically and a
multithreaded program would break. If there were allowed atomic in front,
the compiler would either generate the correct code or report an error.


"Everything else" are high-level synchronization algorithms: spinlocks,
mutexes, semaphores, etc. The 'atomic' does not "do away", it _adds_ the
guarantee of atomicity of memory operations. These (along with preventing
arbitrary statement reordering) are the basic guarantees needed to write
safe multithreaded code without resorting to inline ASM.

Wouldn't it be nice if you could instead of

--
pthread_mutex_lock(&lk);
x += 3; (x86 ASM: addl $3, x)
pthread_mutex_unlock(&lk);
--

write just 'x += 3;' and be *sure* that the compiler has generated correct
code (ie. used atomic instructions) without overheads of function call,
mutexes, and potential sleeping and kernel entry. If the required atomic
code sequence cannot be generated for the target architecture, the
compiler would be *required* to report an error instead of silently
generating incorrect code as is the case now.

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]