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