06-May-2013 14:06, Mehrdad пишет:
On Monday, 6 May 2013 at 09:35:59 UTC, Dmitry Olshansky wrote:
You have to read a field to know what to do next, and the other
processor may as well write to it.
That never happens, though. _static is only written to inside a lock,
Yes, but the 1st processor may read _static exactly when the 2nd is
inside the lock and writing to that field. Then chances are it will read
whatever partial state there is written.
and the check is inside a lock, hence the other processor can't be
writing to it when it's being read...
Surely it can. 1st processor takes the lock and write while the second
one reads static_ to call Get.
Maybe I misunderstood what you're saying?
I bet you just mystified the pattern a bit by relying on indirect call.
In pseudo-code what you do is this:
read static_ // 1st processor may be reading here
if static_ is NullValue //that is indirect call
lock(static_){
check again
write static_ //while 2nd one writes here
}
else
call static_ -~~-> get
I claim that 'read static_' better be "protected" against that 'write
static_' inside the lock.
One way is to ensure write is atomic w.r.t. that particular read
operation e.g. by hardware acquire-release, or via both reads/writes
being atomic.
On x86 word-sized reads/writes are atomic anyway (iff aligned apparently).
The neat stuff about that TLS pattern was that you need not to rely on
hardware specific support.
--
Dmitry Olshansky
