[cpp-threads] RE: C++ Connections proposal

[Boehm, Hans]

[Sent to publicly archived list, since I would like to see any
follow on discussion archived.]

Here are some reactions, to hopefully get a discussion about the threads
interface started:

- [Mostly an aside.]  I actually don't think that the reasons
the library approach doesn't work are that straightforward.  The
pthread approach comes surprisingly close to working.  The
"correctness argument" is roughly as follows:

	1) Races are disallowed.
	2) Outside of locked regions any transformations
	   performed by a sequential optimizer are not observable
	   by another thread, because no shared variables may
	   be accessed by another thread.
	3) Inside locked regions, my thread has exclusive access
	   to the shared data and hence again transformations performed
	   by a sequential optimizer are not observable.
	4) The sequential optimizer cannot move any operations across
	   synchronization operations, since those are treated as
opaque,
	   and are thus presumed to read and write arbitrary memory
	   locations.

Things break for moderately subtle reasons, namely the tendency of
sequential optimizers to introduce extra writes, and the fact that
you can't define a data race without some sort of concurrent program
language semantics.

- I don't have a strong feeling one way or another about active objects.
Based on what I've seen it seems like a good idea.
The idea of having a blocking destructor as a join replacement struck
me as elegant.

- I would need considerably more evidence to be convinced that we should
include coroutines here.  If you mix coroutines and threads, presumably
coroutines have to use a locking discipline that's very similar to
preemptive threads anyway.  Do we get more than a confusing mixture of
two scheduling disciplines?

- I am opposed to a mutual exclusion mechanism in which all public
member
functions implicitly acquire an object-specific lock on entry and
release
it on exit.  That's simpler than possible.  There needs to be an easy
way to acquire a user-determined lock inside a block and to export some
member functions that don't acquire locks (e.g. to access read-only
state)
even if others do.  I need to be able to associate locks with e.g.
array sections.  I think it also leads to the kind of
"over-synchronized"
libraries that we saw in Java 1.0.  (I'm probably an extremist on this
issue.  I don't even like RAII for locks that much.  It often matters
a lot exactly how long and where you hold a lock, either for performance
or to avoid deadlocks.  I think that making it implicit hides a hard
problem
that you can't avoid thinking about.  Locks are hard, and I don't think
there's a way around that.)

- Ugly detail: Unfortunately, I think it's unavoidable that the real
proposal
minimize keyword introductions, and that any new short keywords start
with
a double underscore.  Anything else breaks existing code.  And there is
very
little that will generate as much opposition as quickly as breaking
existing
code.  All the recycling of keywords in C++ unfortunately has a good
reason.
It's too early to worry about that a lot, but it's worth keeping in
mind.

Hans