Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : David Schwartz
Date : Tue Jul 19 2005 05:58 am


"Mayan Moudgill" <mmoudgill@sandbridgetech.com> wrote in message 
news:11dpnqkhea1gr8a@corp.supernews.com...

>>     Exactly, and that's why it should not be part of the C language. The 
>> C language should be about how you get the hardware to do things, not how 
>> the compiler emits code.

> I think you're missing the point. The "abstract machine" used in the C 
> language standard(s) to specify the behaviour of a C program a 
> single-threaded mode. As such, a compiler is allowed to do *any* 
> optimization that would preserve the behavior of the program when run 
> single-threaded, even if it changes the behavior of the program when run 
> multi-threaded. The optimization above is one such example.

    Right.

> Lets get more concrete. Suppose we have some multi-threaded code such as:
>   static volatile unsigned turn;
>   static int result;
>
>   void
>   update_result( int n, int me)
>   {
>     while( turn != me ) { };
>     result += n;
>     turn = (me+1)%NTHREADS;
>   }
>
> Unfortunately, according to the standard [see 5.1.2.3], the compiler is 
> free to implement this as though it were written as:
>
>      result += n;
>      while( turn != me ) {};
>      turn = (me+1)%NTRHEADS;
>
> OR
>      while( turn != me ) {};
>      turn = (me+1)%NTHREADS;
>      result += n;

    Not just the compiler, the CPU, the motherboard, anything at all.

> Now, in this example, the compiler reordering can be inhibited by using 
> volatile-qualifying result.

    Right, but that doesn't help because the CPU might reorder too. The 
motherboard might. The memory hardware might. Some new thing that hasn't 
been invented yet might.

> Lets look at another example:
>
>     update_result(foo(), me); /* foo() is a long-running function */
>
> The compiler is free to treat this code as though it were written:
>     while(turn != me ) {};
>     result += foo();
>      turn = (me+1)%NTHREADS;
> where now the lock is going to be held for a much longer time than the 
> programmer anticipated.

    Right.

>>    Seriously, it is a *huge* layering error to think of the language 
>> specification as telling the compiler what to do. The compiler must do 
>> whatever it takes to make the *platform* do what the standard requires. 
>> The standard specifies what happens when you run the code

> And, unfortunately, the standard does *NOT* specify what happens when you 
> run the code multi-threaded. So, the standard has to be modified to handle 
> multi-threaded programs. How would you propose to do that? In particular, 
> how would you alter the standard to prevent some of the problems shown 
> above from occurring?

    I would not change the C standard unless a method could be devised that 
wasn't specific to some types of hardware or some threading styles. I would 
*not* assume SMP hardware. I would *not* assume that all memory is visible 
to other threads.

    In any event, the problems have nothing to do with compilers or compiler 
optimizations. Any optimization the compiler could make, the CPU could 
theoretically make. Other devices could make them too. The standard is about 
what the code *does*, not what instructions it consists of.

    DS

.