RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
Peter Dimov <pdimov@mmltd.net> wrote:
Alexander Terekhov wrote:
Peter Dimov wrote: <snip>
The observable behavior is
write volatile @a 1
nop
read volatile @a x
nop
write volatile @a x-1
nop
exit(x-1)
push 0 call _exit
in the first case, and
Happy now (debugger notwithstanding)?
No. A conforming compiler is not allowed to do that.
C'mon, volatile is brain-dead.
Nobody's arguing otherwise. ;-) But a nop it isn't.
I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable", the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule. I expect most implementations treat "observable" as "observable by a software or hardware debugger", but of course the standard doesn't and can't say that.
Ben Hutchings wrote:
Peter Dimov <pdimov@mmltd.net> wrote:
Alexander Terekhov wrote:
C'mon, volatile is brain-dead.
Nobody's arguing otherwise. ;-) But a nop it isn't.
I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable",
A memory access is observable if and only if the variable is volatile. 1.9/6.
the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule.
A compiler is not allowed to alter the observable behavior under the "as if" rule. 1.9/1.
Peter Dimov wrote:
Ben Hutchings wrote:
Peter Dimov <pdimov@mmltd.net> wrote:
Alexander Terekhov wrote:
C'mon, volatile is brain-dead.
Nobody's arguing otherwise. ;-) But a nop it isn't.
I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable",
A memory access is observable if and only if the variable is volatile. 1.9/6.
Yes, I understand what is observable (extensional definition). Yet the real meaning of "observable" (intensional definition) is vague (and understandably so).
the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule.
A compiler is not allowed to alter the observable behavior under the "as if" rule. 1.9/1.
Yet there is no statement of *how* the observable behaviour can be observed. Observation is outside the program and outside the standard and so practically implementation-defined. However, I do feel that Alexander's interpretation of volatile memory access is perverse. Ben.
Ben Hutchings wrote:
Peter Dimov wrote:
A memory access is observable if and only if the variable is volatile. 1.9/6.
Yes, I understand what is observable (extensional definition). Yet the real meaning of "observable" (intensional definition) is vague (and understandably so).
Oh well. There is a clear definition of "observable" in the standard. But we know that this is not the real meaning of "observable". Hence, there is no clear definition of "observable" in the standard. Therefore, a compiler is allowed to compile all programs to nops.
the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule.
A compiler is not allowed to alter the observable behavior under the "as if" rule. 1.9/1.
Yet there is no statement of *how* the observable behaviour can be observed. Observation is outside the program and outside the standard and so practically implementation-defined.
There is no statement of how calls to I/O library functions can be observed. Therefore, the compiler is allowed to not call them. There is no statement of how 1+2 can be verified to yield 3. Therefore, the compiler is allowed to substitute 5.
Peter, --- Peter Dimov <pdimov@mmltd.net> wrote:
Ben Hutchings wrote:
Peter Dimov <pdimov@mmltd.net> wrote:
Alexander Terekhov wrote:
C'mon, volatile is brain-dead.
Nobody's arguing otherwise. ;-) But a nop it isn't.
I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable",
A memory access is observable if and only if the variable is volatile. 1.9/6.
the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule.
A compiler is not allowed to alter the observable behavior under the "as if" rule. 1.9/1.
I recently read the article "Double-Checked Locking, Threads, Compiler Optimizations, and More" of Scott Meyers where he touched the Sequence Points and Observable Behavior, Compiler Optimizations and Instruction Reodering. He is more convincing than Alexander; "road to the thread-safe code isn't paved with volatile". (the presentation is available from http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf) Regards Valery Salamakha _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
participants (3)
-
Ben Hutchings -
Peter Dimov -
val salamakha