On 20 December 2006 20:16, Seongbae Park wrote:
> On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> ...
>>> We (in a major, commercial application) ran into exactly this issue.
>>> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
>>> (it is a barrier across which neither the compiler nor CPU will reorder
>>> things). Failing that, no-op cross-library calls (that can't be inlined)
>>> seem to do the trick.
>>
>> This simply means you have failed to correctly declare a variable
>> volatile that in fact /is/ likely to be spontaneously changed by a
>> separate thread of execution.
>
> The C or C++ standard doesn't define ANYTHING related to threads,
> and thus anything related to threads is beyond the standard.
> If you think volatile means something in an MT environment,
> think again.
No no, I fully appreciate that; what volatile means is simply that the
object may change outside the control or knowledge of the compiler, the
particular mechanism does not matter at all, and that is all that is relevant
for the purpose of my argument.
cheers,
DaveK
--
Can't think of a witty .sigline today....
