Memory model

[Hans Boehm]

On Sat, 26 Feb 2005, Peter A. Buhr wrote:

> Hans, this URL hangs for me and all my students, but we still managed to get a
> copy of the paper.
Sorry about that.  The correct URL is
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html.  It looks
like there is a separate HP internal URL, and I got that one by mistake.

...
> As you point out in the footnote on page 3:
>
>  All these functions (referring to the pthreads synchronization routines) would
>  have to be recognized by advanced compilation systems so that memory operations
>  and calls to these functions are not reordered by optimizations.
>
> Clearly, for any compiler to recognize a routine implies that routine name is
> now a "keyword", and hence, part of the language. That is, every C compiler has
> to be cracked open and appropriate code added to deal with pthreads. The Java
> people often do the same thing: they add a magic routine, exception, or
> variable name to make a new feature work, and then claim that they did not
> change the language. I call a spade a spade, and I claim it is the same or less
I think you're reading way too much into that quote from the pthreads
standard.  I know of no compiler that actually does this, as described.
And as far as I can see, it couldn't possibly work.  The compiler may
actually see a call to f() in some external library.  And f() may
happen to do nothing but call pthreads_mutex_lock().  (The rest of the
footnote points out that this fails with indirect calls.  But it should
emphasize that this is completely unworkable, and does not reflect
reality. The quote may have been intended for pure whole program
compilation systems, which I think don't really exist for C++.)

All real implementations of which I'm aware:

1) Put any necessary hardware memory barriers in the implmentations
of the library routines, and

2) Have the compiler treat the pthread_ calls as opaque.  Since they
are opaque they are automatically treated as potentially reading and/or
modifying all shared memory locations.  Thus the compiler cannot
normally reorder references to shared memory around the calls.

> work to add a new language feature correctly as it is to do it by the back
> door. The fact is that pthreads is embedded in C and UNIX at such a level that
> it is becoming a major threat to any further advancement in concurrent
> programming.  For example, in UNIX, when a system routine is designated
> thread-safe, it often means only with respect to pthreads, which precludes
> other concurrent language approaches. In uC++, we have an almost complete
> pthreads simulation hidden under the covers and use it to "trick" UNIX system
> routines to call back to uC++ so all the locking is consistent. It's not easy
> to do and it's fragile.  You might say, just use pthreads to implement
> uC++. But pthreads has its own specific design, which is not compatible with
> other designs, making simulation impossible (e.g., scheduling of threads).
>
> What I'm saying, Hans, is that the 98% of the time you think that a thread
> library does work, this is only true for pthreads and not any other "pure"
> library approaches, i.e., one where the compiler knows nothing about the
> library itself.
Actually the 98% refers to the cases in which "fully synchronized" code
is appropriate.  A pure thread-library-based can never guarantee
correctness of interesting multi-threaded code, even for those 98%.

As to thread-safety applying only to pthreads, I agree that's generally true.

But I'm not at all convinced that there is a real way to avoid having the
system libraries depend on the one standard thread implementation for that
platform, whatever it may be.  I think we will increasingly see "thread hot"
libraries, which create threads internally.  Thus the library implementor
needs to commit to some model.  And I don't know how to mix thread models
without creating disaster.  Nor is it clear to me that we can, or should,
address this.

Hans