Re: How to implement readonly property
Re: How to implement readonly property
- Subject: Re: How to implement readonly property
- From: Greg Parker <email@hidden>
- Date: Fri, 07 Dec 2012 15:49:53 -0800
On Dec 7, 2012, at 2:04 PM, Ken Thomases <email@hidden> wrote:
> On Dec 7, 2012, at 3:08 PM, Greg Parker wrote:
>>
>> You can't assume that any instance variables of a newly initialized object have been zeroed out when
>> * you are reading them from threads other than the one that allocated the object and
>> * there is no synchronization between the allocating thread and the reading thread.
>>
>> In ordinary code there is only one thread involved, or there is already some thread synchronization somewhere.
>>
>> For example, the allocating thread acquires a lock before writing the new object's pointer somewhere that the reading thread can see it, and the reading thread takes the same lock before reading the object pointer. That lock is sufficient synchronization to make it work.
>>
>> You'll only run into trouble if you are trying to use lock-free multiprocessing techniques and you don't use enough memory barriers.
>
> But this means that dispatch_once() is not uniquely unsafe. It can fail only in the exact same scenarios where a thread other than the one which allocated an object might see uninitialized values for generic instance variables. Such scenarios are, of course, unacceptable and so proper synchronization is necessary when passing object pointers between threads, full stop. There's no special care necessary to make dispatch_once() safe, there's just the ordinary care necessary to make passing of object pointers between threads "sane".
That's right. The problem specific to dispatch_once() is that people sometimes use dispatch_once() in lieu of other synchronization expecting dispatch_once() itself to provide more synchronization than it actually does.
> You said that dispatch_once() doesn't promise to provide memory barriers, but, since the use of GCD hasn't brought catastrophe down on all of our heads, I assume that dispatch_async() and the like do provide such memory barriers. Likewise, NSOperationQueue, -performSelector:onThread:..., and the like must also. Is that right?
I would expect that any multiprocessing primitive that does not provide sufficient memory barriers for some uses would document that fact loudly. dispatch_once()'s storage is one documented example of missing barriers. Some of the OSAtomic functions are another example. But pretty much everything heavier-weight than that ought to provide complete memory barriers for any clients.
> If you wanted to be paranoid about using an instance variable as a once predicate, is it sufficient to use OSMemoryBarrier() in the -init method of the object? Or perhaps there needs to be another call to OSMemoryBarrier() immediate before the dispatch_once() call, too.
Maybe. It depends on the architecture and the precise implementation of dispatch_once().
My guess is that OSMemoryBarrier() in -init is sufficient for dispatch_once(&ivar) on all current OS X and iOS architectures and any other reasonable architectures, and is required on some of them.
(As usual, the "unreasonable" architecture is the DEC Alpha, whose memory consistency rules were too loose for mere humans to manage correctly. It looks like everyone learned since then that putting zero data-dependency enforcement in the CPU was a step too far.)
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden