9de
Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Mayan Moudgill
Date : Fri Jul 22 2005 08:47 pm

Joe Seigh wrote:

> Mayan Moudgill wrote:
> 
> 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.

So what synchronization APIs would you like to see supported?

We've got a somewhat myopic view of the world, since we're producing 
most of the low-level multi-threaded code that is being executed on our 
processor.

We've also got a great deal of flexibility since we're implementing our 
own compiler, and we can put in any extensions we want.

We're also pushing the compiler into directions well beyond whats 
generally available in most other products - we will, for instance, 
analyze a whole program, discover that a particular array is better laid 
out differently, and reorder it and all other references to it. Or, we 
will discover that a global variable can be eliminated away through a 
variety of techniques.

This, occasionally, leads to us blowing up multi-threaded code.

> 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.

Absolutely.

For instance, if you look at the following code:
int
main(void)
{
   while(1) {};
   return 0;
}

Most people might look at it and say non-terminating program. In 
actuality, the compiler is free to eliminate that infinite loop [See 
5.1.2.3 from the C99 spec]. I wonder how much code that would break.

>  Once you put in official thread support 
> you can
> be rigidly restricted to the rules.   No more coding outside the box.

But we're not looking for thread semantics etc.; we're looking for more 
primitive notions, which are necessary to change the C semantics to 
allow different thread/synchronization models to be implemented safely. 
For instance, neither "__barrier" or "__spin" tie one to a specific 
model of threading - they just tell the compiler (or, equivalently, 
modify the semantics of C) enough that it won't break multi-threaded code.

.

0