Memory model

[Peter A. Buhr]

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! ;-)