[cpp-threads] C++ committee meeting in Mont Tremblant

[Boehm, Hans]

I'd argue for a solution here that I know Peter isn't going to like:

A) Build on top of pthreads.
B) If you have a really, really good case that (A) doesn't work, extend
pthreads as necessary to make it work.

Mixing thread libraries seems fundamentally broken.  Allowing for
replacement at link time seems barely feasible as Peter states, if there
is no hidden interface between the thread library and the rest of the
system, and you standardize the size of objects like locks.  But this
seems like an ugly thing to require with a really, really good case.
And if you have that, a pthreads extension seems less painful.

On top of that, I expect that a production thread library (or more
likely kernel thread scheduler) will increasingly need to know more
about the hardware (hardware threads vs. cores, logical distance between
cores and memory, hardware hacks to identify dirty registers, etc.) than
anybody else should really need to know.  I think that code should be in
exactly one place.

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Peter A. Buhr
> Sent: Tuesday, October 18, 2005 10:31 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] C++ committee meeting in Mont Tremblant
> 
> 
>    Date: Tue, 11 Oct 2005 11:08:11 -0700
>    From: "Boehm, Hans" <hans.boehm at hp.com>
>    Reply-To: cpp-threads at decadentplace.org.uk
>    Sender: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk
> 
>    I think I can offer a bit more clarification w.r.t. C 
> compatibility:
> 
>    My impression is that vendors tend to favor solutions that don't
>    preclude them from doing interesting things in header 
> files that are
>    shared between C and C++.  Hence there tends to be a push 
> for low-level
>    solutions that work with both, plus possibly a higher 
> level C++-only
>    solution that interoperates with it.  This is clearly more 
> important for
>    certain parts of the interfaces than others.
> 
>    Hence the push for both (1) and (2), and similarly for a low-level
>    C-compatible atomics package, as well as a higher-level 
> one built on top
>    of it.
> 
> I think there is a extremely important issue embedded in this 
> point, which I refer to as the pthreads pandemic. UNIX is 
> still based on C interfaces; other large packages, like 
> X-windows, are also C based. These systems rely more and more 
> on pthreads to provide "thread-safe" interactions, which 
> means pthreads locks are being embedded in more and more 
> library code. Linker tricks are used to select the pthreads 
> library or nullify the locks when a program is sequential. 
> However, for concurrent languages or libraries that have 
> their own threading/locking model, but still need locking 
> across system calls, there is a huge problem. What these 
> concurrent systems want is their own locks to be used when 
> calls are made to thread-safe system/library routines, rather 
> than pthreads locks. But these routines hard-code the lock 
> storage and calls to the acquire/release routines. If you can 
> build your concurrent language/library on top of pthreads, 
> then it is possible to directly use these pthread locks. 
> However, when a pthread lock decides to block, it goes to the 
> pthread runtime system to schedule the next thread, which has 
> it's own idea of how scheduling should be done. If this 
> matches perfectly with a particular language/library model, 
> you are good to go; if it doesn't match, it's a show stopper. 
> For example, a concurrent language/library may have a form of 
> priority scheduling which has no counterpart in pthreads.
> 
> To get thread-safe locking across existing C 
> routines/applications in uC++, we had to built an entire 
> pthread interface, which uses our own locks, and yields to 
> the uC++ runtime scheduler. We then use linker tricks to 
> replace the standard pthread library with the uC++ 
> simulation. Furthermore, we have to overlay uC++ locks in the 
> storage area provided for pthread locks set aside by the 
> system libraries.  All of this is a giant kludge, and is 
> totally unsatisfactory.
> 
> So there are strong reasons to have a mechanism that provides 
> some very basic concurrency capabilities that span both the C 
> and C++ domains, given that many large applications will 
> continue to be developed in C but used by C++ programms. 
> However, the issue is more complex because it depends on the 
> specific threading model used by an application. It might be 
> necessary to define a simple API for locking, which sets 
> aside a minimum block of storage for a lock, and a mechanism 
> to initialize and access the storage. Each concurrency 
> runtime than uses this storage and routines to enable it's own locks.
> 
> As you can see, this problem is complex and needs some 
> thought, if system libraries are going to be thread-safe 
> across a number of different concurrent languages and libraries.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>