Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Joe Seigh
Date : Fri Jul 22 2005 06:28 pm

Mayan Moudgill wrote:
> Joe Seigh wrote:
>>
>> Actually, we're probably better off without it.  Once they put thread 
>> support
>> in C we'll be in the same situation Java is in where you can't add 
>> anything
>> without adding support directly in Java itself, e.g. JSR 166.   Where 
>> do you
>> think the stuff they added in JSR 166 came from?
>>
> 
> Interesting.
> 
> Our original motivation for extensions came from the desire to write 
> various atomic operations in C. We wanted to do:
>   void
>   atomic_increment(
>     volatile int * p
>     )
>   {
>     do {
>       int x = __load_locked(p);
>       x++;
>     } while( !__store_conditional(x,p);
>   }
> [We've already added two extensions, which can be modelled as functions].
> 
> We found that the compiler was:
> a) inlining functions of this form.
> b) then moving code around in somewat unpleasent ways.
> 
> We introducted the __barrier(); "call" to inhibit the compiler from 
> doing this. [__load_locked/__store_conditional are also __barriers 
> before/after the operation].
> 
> Another problem came from spin-lock wait loops.
>   void
>   spin(unsigned n)
>   {
>     unsigned i;
>     for( i = 0; i < n; i++ ) {
>     }
>   }
> The compiler was eliminating the wait-loops [as it should]. We had to 
> introduce a mechanism to inhibit this optimization.
> 
> It turns out that, as the compiler starts optimizing more, and worse, 
> doing whole program optimizations, it becomes critical with 
> multi-threaded programs to make sure that the compiler can distinguish 
> between optimizations that would be correct in single-threaded C but are 
> invalid in multi-threaded codes.
> 

What you won't get is support for writing your own synchronization api's,
Not unless you can construct them out of the synchronization functions they
give you.  Probablly something like the atomic stuff in JSR 166.  You
might want to take a look at that.

Also look at the current discussion of what's being looked at for C++.
http://decadentplace.org.uk/pipermail/cpp-threads_decadentplace.org.uk/

What people don't realize is that most C compilers can't do all the optimization
they could do because they'd break all kinds of things,  Linux kernel and lot's
of device drivers for instance.  Once you put in official thread support you can
be rigidly restricted to the rules.  No more coding outside the box.




-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.