Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Mayan Moudgill
Date : Mon Jul 25 2005 10:31 pm

David Hopwood wrote:
> 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.
> 
> 
> Those of us who argue against direct use by applications of low-level
> primitives dependent on particular machine-level shared memory models,
> are not doing so simply because we have plucked an agenda out of thin air.
<some interesting arguments snipped>

I think that one possible answer to your objections is to add the 
semantics at the _language_ level, and let the compiler (+run-time) take 
over the responsibility of picking the correct primitives.

> There's quite a close analogy between depending on low-level shared
> memory primitives, and the kind of direct hardware access, bypassing
> the OS, that many MS-DOS programs used to do.

And as is still done in the embedded world. I think you're implicitly 
assuming:
- performance doesn't matter, because CPUs are powerful enough
- the difference in performance between using low-level APIs and 
high-level APIs is not significant at the system level.

Neither of these assumptions holds once you start working in the 
embedded arena.

.