Re: Named shared memory without synchronization
"Ben Voigt" <rbv@nospam.nospam> wrote in message
news:%234RCo0$DHHA.4832@TK2MSFTNGP06.phx.gbl
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:%23nN8Pg$DHHA.3596@TK2MSFTNGP03.phx.gbl...
"Ben Voigt" <rbv@nospam.nospam> wrote in message
news:OyBcPD$DHHA.3520@TK2MSFTNGP04.phx.gbl
wouldn't this be atomic?
LOCK DEC ptr [eax]
I believe so. _InterlockedDecrement intrinsic is doing LOCK XADD,
for what it's worth.
Is that because condition flags (zero, negative, overflow) are set
differently for DEC and XADD?
Possibly. That's my guess also.
Of course the compiler isn't required to generate the LOCK prefix...
with volatile would it be forbidden to?
I don't see why it would be forbidden, but it's probably not required
either. I don't see VC8 32-bit compiler doing it for volatile
variables - maybe 64-bit compiler does.
Since the semantics of (*p)-- specify a read and a write, and the
compiler isn't allowed to optimize away reads or writes on volatile
variables, I thought maybe it would have to generate separate read
and write instructions.
VC8 32-bit compiler definitely doesn't do that. x-- for a [volatile int
x] generates a single ADD instruction with an immediate argument of -1
(the same for a non-volatile variable generates a SUB with argument of
1 - a curious fact I have no explanation for).
The requirement for separate read and write only really makes sense for
memory-mapped hardware I/O registeres - do these even exist with x86
architecture? The compiler is only required to behave "as-if" it
followed the rules, to prove a violation you must be able to observe it
externally.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925