Re: Named shared memory without synchronization
"Dan Schwartz" <DanSchwartz@discussions.microsoft.com> wrote in message
news:AEAAB6A2-9222-4473-9EAA-83A2C251DA0A@microsoft.com
I see a very obvious problem. (*x)-- operation is not atomic - it
involves reading a word from memory, decrementing, and writing new
value back. Consider this scenario: the server reads *x which
happens to be 1. Right after that the client writes, say, 10 into *x
and goes back to work, safe in the knowledge that it has performed
its notification duty. But the server saw 1, not 10. So it
decrements and writes 0 back into *x, overwriting the client's
notification. A second later the server would consider the client
hung and kill it.
For the record, I've actually considered this scenario, and decided
that it would be acceptable that the timeout be always set to one
unit more of whatever timer resolution is used (see below).
I don't quite see how this helps. What difference does it make if the
lost value is 11 rather than 10, or if it's getting lost when going from
2 to 1 rather than from 1 to 0? Either way the client ends up being
killed prematurely, while in perfectly good health.
1. That the integer pointed at by x isn't somehow corrupted by a
combined read/write.
I'm not sure what you mean by "combined read/write". There ain't no
such thing.
I suggest that for any non-primitive (by this I mean a type wider
than the CPU register width), there is.
We probably take "combined read/write" to mean different things. I
thought you were talking about some kind of operation that could read,
modify and write memory in one go atomically. You seem to mean something
else.
--
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