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

[Peter A. Buhr]

   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.