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