Possible language changes

Doug Lea dl at cs.oswego.edu
Tue Mar 1 19:18:22 GMT 2005


> 
> 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".


Unless anyone objects to any of these within, say, a week, I think
they should be marked as settled, so could be put in some document
for next standards meeting as a preview of the full changes.

> 
> 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.

Can anyone think of any compelling objection to this?
It seems like the only viable approach. It would also be
good to settle on this soon to get reaction.


> 
> 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? 


It would be really helpful to have use cases here to look at.
Offhand, deprecating sounds fine to me.

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

I second the request.

-Doug








More information about the cpp-threads mailing list