Low-Lock Singletons In D
Dmitry Olshansky
dmitry.olsh at gmail.com
Mon May 6 04:21:29 PDT 2013
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
More information about the Digitalmars-d
mailing list