Subj : Re: Adding thread support for C...
To   : comp.programming.threads
From : Joe Seigh
Date : Tue Jul 26 2005 08:20 am

David Hopwood wrote:
> Joe Seigh wrote:
>> 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.

I'm talking about portable api's so by definition they're not dependent
on platform specific memory models.

> 
> The arguments supporting this view are:
> 
>  - designing correct lock-free algorithms is difficult even for experts.

The lock-free algorithms supported by the api's would have already
been designed. 
> 
>  - most application programmers are not experts in this area;
>    observation and experience, not just opinion, suggests that they
>    frequently misunderstand how to use these primitives either correctly
>    or efficiently.

Are you talking about threading or lock-free?   The same could be said
about either.
> 
>  - the more such APIs attempt to optimize for particular machines, the
>    more complex and nonportable they become. Some proposed primitives
>    (e.g. data-dependent barriers) seem AFAICS to be based more on
>    coincidental properties of the implementation of current processors
>    than on any documented and well-understood memory model.

The api is portable.  You can keep saying otherwise but that doesn't make
it true.  You just need to add a memory barrier for platforms that don't
have natural data dependency.  See the Linux kernel for an exaple of this.
You can't keep hardware architects from breaking things they don't understand.
Saying something like well we should use Posix then is specious.  It's not
the hardware architects that guarantee that Posix is portable, it's the
Posix implementers who do.  Same with any other "portable" api.

> 
>  - if these primitives were used only by language implementations,
>    operating systems, and to provide higher-level APIs, the complexity
>    cost and the porting effort would be amortized over all the apps
>    using those languages/OSes/APIs. If they are used directly by
>    applications, these costs have to be paid per-appication.

You're mixing two things here.  I've already addressed the porting issue.
All api's have various costs and it's a trade off decision as whether to
use them or not.  Just because the api exists doesn't mean that it has
to be used in all cases.
> 
>  - dependence on specific current machine-level memory models by
>    applications will make it more difficult to support those applications
>    on future hardware.

Portability.  I don't think that word means what you think it means.

> 
>  - for many, probably most, multi-threaded applications, using these
>    primitives would not improve performance significantly or have any
>    other benefit.

So you don't use them in that case.  You don't use threading when
it won't improve performance or have other benefits either.  What's the problem?
> 
> 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. Just as in that case,
> emulating the behaviour of current machines in order to support those
> applications will be possible, but it will be complex, unreliable,
> and slow. The complexity is the most serious problem.
> 

There's no analogy here.  The example you cite here didn't use an api that
could be ported.


-- 
Joe Seigh

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

.