Memory model

[Boehm, Hans]

Peter -

I think the three levels we were looking at are roughly:

1) Memory model
2) Atomic operations and perhaps primitives for building locks
3) Higher-level standardized thread library

In my opinion, the large majority of programmers will care only
about (1) and (3).

The argument for looking at the memory model before, or in parallel
with (3) is that:

a) If you look at current standard practice, that's the one place
were things are really intolerably broken. 

You might not like the pthreads interface.
But there is nothing to prevent that interface from being used
in correct multithreaded programs, except that the current de
facto language memory model rules allow the compiler
to introduce races and thus break your program.
(The same applies to win32 threads, Boost,
uC++ (I suspect), etc.)  There is a lot more detail about these
issues in my PLDI 2005 paper.
(draft at http://lib.hpl.hp.com/techpubs/2004/HPL-2004-209.html)

b) As Stroustrup suggested, I think it will be
difficult to get agreement or standardization on (3).  By
starting there, there is a substantial danger that we'll never get
around to the issues for which we can really have an impact.
As Doug points out, that shouldn't stop us from trying.  But
we shouldn't block everything else on it.  (I suspect things
have gotten worse since 1996, since at least win32 threads and
pthreads now have a significant body of code behind them.  And
then there's Boost, uC++, OpenMP, ACE, NSPR, Cilk, ...  And I
doubt it would be technically easy to make OpenMP style
programming fit.  But it's also not something we can ignore.)

c) If you look at the Java memory model, there is lots of reason
to believe that we can formulate a memory model that makes sense
across a wide variety of synchronization primitives.  Generally,
we care only which pairs of synchronization operations (e.g.
unlock/lock on a given lock, or volatile write/read on the same
variable) ensure visibility between threads.  I think it's quite
viable to have the language define a general memory model, and then
to have a particular high level layer simply define this piece.
The fundamental issues are the same whether we assume the higher
layer is pthreads or uC++, or probably even OpenMP.

Hans

> -----Original Message-----
> From: Peter A. Buhr [mailto:pabuhr at plg.uwaterloo.ca] 
> Sent: Sunday, February 20, 2005 7:24 PM
> To: hsutter at microsoft.com; Boehm, Hans; 
> ben at decadentplace.org.uk; kevlin at curbralan.com; 
> andrei at metalanguage.com; magedm at us.ibm.com; pugh at cs.umd.edu; 
> rcbilson at uwaterloo.ca; dl at cs.oswego.edu; asharji at plg.uwaterloo.ca
> Subject: RE: Memory model
> 
> 
> I feel bad about not responding sooner. I feel like I killed 
> the discussion.
> 
> Any who, I finally read through the email I got so far, 
> thought about it for a while, and want to ask a question. 
> Think of this question like those posed by Watson to Sherlock 
> to give Sherlock the chance to show off this sagacity.
> 
> The general feeling is that 3 levels is a good thing (Martha 
> S): memory model, thread/lock library, high-level thingy, and 
> do them in that order.  So I'd like to ask why not do them 
> the other way around.
> 
> I'll use uC++ as an example, but without loss of generality, 
> you can use almost any other high-level concurrency system. 
> So in uC++, programmers use task, monitor and 
> coroutine-monitor objects to build arbitrarily complex 
> applications (Java programmers use thread and monitor). These 
> facilities are integrated with the other features of the 
> language, e.g., polymorphism, exception handling, and I/O 
> (Java's facilities are not integrated as well).  Now from a 
> programmer's perspective in uC++, no memory model per se is 
> required; if you use the concurrency facilities, the 
> application works. If you stray from the uC++ concurrency 
> facilities, the application may not work. Very simple, very 
> elegant, and often very efficient. At the end of the day, 
> it's what makes application programmers very happy, i.e., a 
> high-level, working, efficient program.
> 
> Now uC++ concurrency facilities are not part of the 
> programming language. But if they were, the compiler would 
> *know* all the magic concurrency points and it would insert 
> all the magic thing-a-ma-bobs to make it work (I don't want 
> to get overly technical ;-). Furthermore, because the 
> compiler *knows* all the magic points, it is free to optimize 
> like Hell around them. And finally because the compiler 
> *knows* if the program is concurrent or sequential there are 
> no problems about under-optimizing in the sequential domain.
> 
> Now I'm fully aware that it's not that simple. But it seems 
> to me that by starting with the high-level thingy approach, 
> you start from a position of strength having maximum 
> knowledge. Personally, I always enjoy working at this level.
> 
> Now if you want to support out-of-the-specified-framework 
> concurrency stuff, that's fine too, and then you have to 
> construct a memory model at some level of strength to support 
> just how far you want to go outside the framework. And 
> finally, if people feel compelled to build yet-another-thread 
> library, and there is nothing anyone can do to stop them, 
> they can rely on the memory model to make it work.  But this 
> begs the question: if the high-level thingy approach is 
> really good, who needs a complex explicit memory model or a 
> thread library?
> 
> At this point, most of you are crying out "how naive can 
> someone be"! Yes, I understand that people would shit on a 
> high-level thingy proposal from great height, and hug the 
> current none-working, difficult to program, non-integrated 
> approaches to their bosoms saying "let's not change a thing". 
> It's just human nature.
> 
> So what's my position? Well, I'm forced to go along with 
> ya'll and build up from a memory model so that I can keep 
> uC++, or things like it, going. But I really think it's 
> putting the cart before the horse, because I believe a memory 
> model only needs to be strong enough to support the 
> high-level thingy stuff, after that it's just icing on the cake.
> 
> Anyway, I have lots more to say about memory models, the 
> pthread pandemic, and high-level stuff, but this is enough to 
> start. Hey, you might kick me off the team now and then I'm done! ;-)
>