Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Mayan Moudgill
Date : Sun Jul 24 2005 12:56 pm

Joe Seigh wrote:

> Mayan Moudgill wrote:
> 
>> 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?
>>
> I deal with various issues depending on what I'm doing at the time.
> I don't think it's worth my time trying to formalize what thread support
> by C should be given it would take a lot of time and effort.  I don't
> think I could counter the agendas others are pushing plus the tendency
> of threading api implementors to have a low opinion of other peoples
> thread programming skills.  This leads to the deliberate omission of
> low level primitives and the inclusion of only the high level api's
> favored by the thread api designers.  Java is a case in point.  And
> JSR 166 is an interesting aspect of this.  The lock-free techniques in
> JSR 166 came from outside of Java, C mostly.  When you end up making C/C++
> like Java, it will be difficult to develop new algorithms in threading.
> You won't be able to cheat and get away with it like you can now.
> 
> Also it's more or a less a moot point as far as I'm concerned.  I'm
> working on trying to stop inventing new threading techniques as it's
> not really a useful activity and it's mostly frustrating being on
> the bleeding edge.
> 
> 

I can see why that might be the case in a traditional 
desk-top/work-station setting. But we're working on hard real-time, 
low-power embedded parts. This means:
- you have to push performance; since, IMO, high-level APIs are usually 
bad performers compared to low-level APIs, we tend to expose a lot more 
low-level APIs to people.
- we're working in an unusual architecture; clusters of 8 way hardware 
multi-threaded, real-memory only, no data-cache processors. In this 
envirnoment, standard multi-threading is, IME, sub-optimal.
- we're working on an embedded part, which means that there is a single 
process, which means that (theorietically) the compiler can analyze and 
optimize every piece of code that will be running.

Now some of these constraints are somewhat unique to us (hardware 
multi-threading, though other embedded designs are headed in that 
direction), but most of them are not. There are quite a few embeded 
parts that will have multiple processors using shared, 
non-hardware-synchronized memory and will be used for hard real-time 
work. These kinds of multi-processor architectures will almost certainly 
demand revisiting threading models.

What does make us unique is that we have the software tool base and the 
motivation to attack this problem *NOW* as opposed to, say, 2-5 years 
from now.

.