Possible language changes

[Boehm, Hans]

Ben -

I think this is useful, but we might be getting ahead of ourselves
a bit.

Should we try to first identify the important issues and then try
to get a preliminary consensus to run past the C++ committee?  I think
your list is helpful in identifying the issues.

Based on an earlier message from Herb Sutter, it sounds like it would
be useful to trey to have someone at the Lillehammer meeting and get
some feedback on some of these issues.  Is someone planning on being
there
anyway?  Does anyone know what the deadline is for getting something
into the mailing for that meeting?

On the memory model side, I think the major identified issue is

1) Do we leave the semantics of programs containing races undefined?
The only people who have commented on this are somewhat in favor, I
think.

Other known issues:

2) Can we restrict the compiler introduction of visible writes to 
only the bit-field case?
I would argue "yes".  Otherwise we need an alternate, weaker
restriction.
Note that the way I've phrased this, it disallows speculative register
promotion, which is now done by many compilers.  I know of no way to
avoid that.

3) Should we allow the compiler to reload local variable from globals,
as some compiler do now.  Assuming the answer to (1) is yes, I think the
answer here is implicitly "yes".

4) Should volatile reads/writes count as synchronization operations and
have acquire/release semantics as in Java?  I would argue yes.  But this
is a significant change on many platforms (though not Itanium), and is
controversial.

5) Should initialization of function-scoped statics be implicitly
synchronized?
I think we need to figure out what implementations currently do.  My
personal opinion is probably no, but I already lost this argument once
when the Itanium ABI was designed.  (Argument pro: The shared variable
is compiler-introduced, and hence it would be very hard for the
programmer
to explicitly synchronize.  Argument con: It introduces potentially
expensive synchronization where it is likely to never be needed,
and they're hidden from the programmer's view.  It
requires the compiler to generate implicit calls into the thread
runtime.
Drastic alternative:  Deprecate the construct in the hard cases.)
Opinions? 

6) I'm sure there are issues with exceptions, but I haven't looked
deeply.  Anybody want to point out what they are?

Anything else?

Hans

> -----Original Message-----
> From: Ben Hutchings [mailto:ben at decadentplace.org.uk] 
> Sent: Sunday, February 27, 2005 5:28 AM
> To: Andrei Alexandrescu; Boehm, Hans; Kevlin Henney; Bill 
> Pugh; Douglas C. Schmidt; Doug Lea; Jim Rogers; Maged 
> Michael; asharji at plg.uwaterloo.ca; Richard Bilson
> Subject: Possible language changes
> 
> 
> Here's a list I came up with some months ago, but only posted 
> to the mailing list that I hastily set up and which we 
> haven't used.  I think I'm going to have a go at drafting an 
> actual proposal soon, but I don't know whether I'm really up 
> to that task.
> 
> I skimmed through the language part of the standard, looking 
> for anything that might be affected by concurrency.
> 
> Most importantly:
> 
> 1.3 [intro.defs] We may need to add definitions of "thread" 
> and other terms.
> 
> 1.9/6-11 [intro.execution] We need to change the 
> specification of the sequencing of operations and the 
> definition of observable behaviour to allow for concurrency 
> and synchronisation.  We may wish to specify more precise 
> semantics for volatile.
> 
> 3.6.1, 3.6.3 [basic.start.main, basic.start.term] We should 
> either specify what happens if main exits or if exit() or 
> abort() is called while multiple threads exist, or else state 
> that this results in undefined behaviour.
> 
> 3.6.2/3 [basic.start.init] We should specify that static 
> initialisation at namespace scope is always synchronised if 
> done while multiple threads exist.
> 
> 6.7/4 [stmt.dcl] We should specify static initialisation at 
> local scope in such a way that it can be or is always synchronised.
> 
> 15 [except] We must change some parts of this slightly to 
> allow for concurrency, including at least 15.1/7, 15.1/8, 
> 15.2/1, 15.2/2, 15.5.3
> 
> Plus optionally:
> 
> 2.11 [lex.key] We may wish to add keywords.
> 
> 6 [stmt.stmt] We may wish to add synchronisation statements.
> 
> 7 [dcl.dcl] We may wish to add some new form of declaration.
> 
> -- 
> Ben Hutchings
> Life would be so much easier if we could look at the source code.
>