it's a rough rough rough draft

[Boehm, Hans]

Thanks.

I think at this stage we should aim for placeholders
for the missing sections.

We can't possibly turn this into a threads introduction.
Nor do I think we should try.  We should reference one.
I think Andrew Birrell's "An Introduction to Programming
with C# Threads"
(http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf)
is probably fine, and has a good intro,
though some of the finer details don't carry
over.  Anyone know of a better one?

Minimal placeholders:

Section 4:

The core of the new Java memory model is to classify synchronization
operations as "acquire" (e.g. lock acquisition) or "release" (e.g. lock
release) operations on some synchronization object.  A "release"
operation has the effect (among others) of ensuring that all memory
operations performed by a thread before the "release" operation
become visible to another thread after it performs a corresponding
"acquire" operation.  Thus, for example a thread that acquires a lock
is guaranteed to see all updates that occurred while another thread
held the same lock.

We plan to pursue a solution based on this notion, where the
set of "acquire" and "release" operations includes both some primitives
from the next section, and a set specified by the applicable operating
system standard (e.g. pthread_mutex_lock() or win32 EnterCriticalSection()).

Section 5:

I would make this much more tentative, e.g. start with:

We are planning to propose a set of atomic operations on shared memory
locations to support lock-free programming.  For each such operation
we will need to specify not only its function, but also the ordering
constraints it imposes, e.g. whether it behaves as an "acquire" or
"release" operation, or neither or both.  For many operations
multiple variants make sense.  We are currently undecided as
to both the syntax of these constraints, and how many variants there
should be.  Thus we omit them for the rest of this presentation.

I think cas should be one of the atomic_ primitives.

Why not turn atomic_int_type into a class and just follow the
java.util.concurrent.atomic.AtomicInteger spec?  (And this is
coming from someone who is at best an agnostic when it comes
to OO stuff :-) )  At this point,
I think there is no reason to diverge from it, except for the
XXXValue() functions, which are Java-specific.  The set there
was pretty carefully thought out and complete.  Except that
I just noticed that getAndBitwiseOr is missing.  Doug?

In any case, atomic_add needs to return a value.

(Actually, I can think of a reason to diverge from it, which would
be to have a single interface for both C and C++.  But I doubt that
would fly.  And eventually there may be reasons to supply the
ordering semantics as a template argument.)

Section 6:

We plan to consider giving an assignment to a "volatile" variable
or field "release" semantics, and read a "volatile" "acquire"
semantics.  This is true for both the new Java memory model and
the current C/C++ ABI for Itanium.  This would better specify
the semantics of "volatile" and allow clean solutions to some common
concurrent programming problems for which locks often introduce
too much overhead.  But we have not yet had enough time to fully
understand the consequences for C++.

> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrei at metalanguage.com]
> Sent: Thursday, September 09, 2004 3:15 AM
> To: Hans Boehm; Ben Hutchings; Kevlin Henney
> Cc: Doug Lea; pugh at cs.umd.edu; Scott Meyers
> Subject: it's a rough rough rough draft
> 
> 
> I made one pass through the doc. It's about pre-alpha quality now. 
> Added a little bibliography, stuff here and there, and lost steam 
> exactly when things were starting to become more interesting. My 
> impression is that we dived in things without keeping the Zen-ish 
> perspective needed at this level of detail. But maybe I'm wrong.
> Any input is welcome. I added Kevlin Henney and Ben Hutchings to the 
> list. Please reply to all.
> I attached the tex and bib files, plus a PDF for your convenience.
> Andrei
>