Re: How to implement readonly property
Le 9 déc. 2012 à 02:27, Richard Heard a écrit :
> Greg,
>
> So, from what you are saying, either of these snippets should be valid, right?
>
>> +(id)sharedInstance{
>>static id _sharedInstance = nil;
>>
>> …
>>OSMemoryBarrier();
>>return _sharedInstance;
>> }
OSMemoryBarrier are not cheap. If dispatch_once uses it only on the write side,
then it should be faster than forcing a full barrier at each access.
By the way, as nobody mention it until then, all this discussion look like to
me as pointless premature optimization. If accessing your singleton is a
bottleneck (and nothing tell us it is), there is probably simpler way to avoid
this cost.
> vs
>
>> +(id)sharedInstance{
>>static id _sharedInstance = nil;
>>
>>static dispatch_once_t onceToken;
>>dispatch_once(&onceToken, ^{
>>_sharedInstance = [[super allocWithZone:NULL] init];
>>});
>>
>>return _sharedInstance;
>> }
>
>
> Any massive advantages / disadvantages with either approach?
>
> -Richard
>
> On 08/12/2012, at 4:45:37 PM, Greg Parker wrote:
>
>> On Dec 8, 2012, at 11:17 AM, Steve Sisak wrote:
>>> At 10:24 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 8, 2012, at 10:06 AM, Steve Sisak wrote:
> Further, if writes were not complete at the end of the block, the
> construct would besentially useless for its intended purpose.
By the way, you're wrong about this too. All @synchronized does is act as
a mutex around a code block. It does not cause the compiler to reorder
instructions and issue memory barriers in such a way that initialization
is guaranteed to precede assignment from the perspective of all threads.
>>>
>>> Please cite a source for this assertion.
>>
>> Source: me, the author of the current @synchronized implementation.
>> @synchronized performs the same synchronization as a pthread mutex.
>>
>>
>>> From:
>>>
>>>
>>>
>>> "If you are already using a mutex to protect a section of code, do not
>>> automatically assume you need to use the volatile keyword to protect
>>> important variables inside that section. A mutex includes a memory barrier
>>> to ensure the proper ordering of load and store operations."
>>
>> To a close approximation, you should pretend that `volatile` does not exist
>> in C-based languages.
>>
>> The above says that if you already have mutexes then you do not need
>> `volatile`. The mutex alone does all of the work.
>>
>> Conversely, `volatile` with no mutex is also not a safe multithreading
>> pattern.
>>
>>
>>> I acknowledge that, without proper memory barriers, double-checked locking
>>> is problematic, but am providing an example using a construct which I'm
>>> fairly sure uses proper memory barriers.
>>>
>>> - (NSDictionary *)someDictionary;
>>> {
>>> if (!_someDictionary)
>>> {
>>> @synchronized (self)
>>> {
>>> if (!_someDictionary)
>>> {
>>> // create a temp dictionary (might take some time)
>>> _someDictionary = temp;
>>> }
>>> }
>>> }
>>>
>>> return _someDictionary;
>>> }
>>
>>
>> The example provided does not use proper memory barriers.
>>
>> In general, memory barriers need to occur in pairs, one on each thread. The
>> coordination of the two memory barriers achieves the desired
>> synchronization, so that both sides observe events occurring in the same
>> order.
>>
>> Mutexes and similar constructs achieve this. The mutex lock() and unlock()
>> procedures form a barrier pair. Code running with the mutex held is
>> therefore correctly synchronized with respect to other code that runs with
>> the mutex held. But code running outside the mutex is not protected, because
>> it didn't call the barrier inside the lock() procedure.
>>
>> In faulty double-checked locking code, the problem is that the writer has a
>> memory barrier but the reader does not. Because it has no barriers, the
>> reader may observe events occur out of the desired order. That's why it
>> fails. (Here the "writer" is the thread actually calling the initializer and
>> the "reader" is a second thread simultaneously performing the double-check
>> sequence.)
>>
>> (Faulty double-checked locking code has a second problem because the
>> writer-side barrier inside the mutex unlock is the wrong barrier to use with
>> a reader that is not locking the mutex.)
>>
>> You need to do one of two things to fix the reader side of a double-checked
>> lock:
>> * add appropriate barriers to the reader side, or
>> * cheat in a way that is guaranteed to work on all architectures you care
>> about.
>>
>> dispatch_once() actually cheats. It performs a very expensive barrier on the
>> writer side (much more expensive than the barriers used in ordinary mutexes
>> and @synchronized), which guarantees that no barrier is needed on the reader
>> side on the CPUs that run OS X and
Re: How to implement readonly property
On Dec 9, 2012, at 1:27 AM, Kyle Sluder wrote: > If dispatch_once() really is unsuitable for use with a dispatch_once_t > stored in Objective-C instance storage, then the correct example in the > paper I've cited might be a sufficient workaround. I thought we had established that, in all sane use cases, an instance variable once predicate is fine. The cases where an instance variable once predicate would be unsafe are exactly the cases where it would be unsafe to access any instance variable, including the isa pointer. So, if you're using the instance in any way, you've already assumed conditions that make the once predicate fine. (And, hopefully, you've more than assumed it, you've ensured it by proper inter-thread communication of the object pointer.) Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement readonly property
On Dec 9, 2012, at 6:53 AM, Ken Thomases wrote: > On Dec 9, 2012, at 1:27 AM, Kyle Sluder wrote: > >> If dispatch_once() really is unsuitable for use with a dispatch_once_t >> stored in Objective-C instance storage, then the correct example in the >> paper I've cited might be a sufficient workaround. > > I thought we had established that, in all sane use cases, an instance > variable once predicate is fine. Hence the hedge. ;-) > The cases where an instance variable once predicate would be unsafe are > exactly the cases where it would be unsafe to access any instance variable, > including the isa pointer. So, if you're using the instance in any way, > you've already assumed conditions that make the once predicate fine. (And, > hopefully, you've more than assumed it, you've ensured it by proper > inter-thread communication of the object pointer.) Yes, but as Greg pointed out the real danger comes from not understanding all the nuances of this, and assuming that dispatch_once is a more powerful synchronization primitive than it really is. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to implement readonly property
On Dec 9, 2012, at 10:37 AM, Kyle Sluder wrote: > On Dec 9, 2012, at 6:53 AM, Ken Thomases wrote: > >> On Dec 9, 2012, at 1:27 AM, Kyle Sluder wrote: >> >>> If dispatch_once() really is unsuitable for use with a dispatch_once_t >>> stored in Objective-C instance storage, then the correct example in the >>> paper I've cited might be a sufficient workaround. >> >> I thought we had established that, in all sane use cases, an instance >> variable once predicate is fine. > > Hence the hedge. ;-) > >> The cases where an instance variable once predicate would be unsafe are >> exactly the cases where it would be unsafe to access any instance variable, >> including the isa pointer. So, if you're using the instance in any way, >> you've already assumed conditions that make the once predicate fine. (And, >> hopefully, you've more than assumed it, you've ensured it by proper >> inter-thread communication of the object pointer.) > > Yes, but as Greg pointed out the real danger comes from not understanding all > the nuances of this, and assuming that dispatch_once is a more powerful > synchronization primitive than it really is. I'm still not understanding the circumspection. The use of dispatch_once() never _contributes_ to unsafe access. It is unsafe if the situation is already unsafe. If you try to avoid using dispatch_once() using other techniques like @synchronized(self), etc., that doesn't help anything. Intellectually, I understand the concern that people will assume that dispatch_once() introduces safety where it doesn't, but as a practical matter I'm finding it hard to imagine a scenario where a) that comes up or b) avoiding dispatch_once() for some vague (to the naive developer) notion that it's unsafe would lead to better safety. Can you or Greg illustrate with an example? I feel that dispatch_once() with an instance variable once predicate _is_ the right answer for the class of problems where people would be tempted to use it and that we should be encouraging developers to rely on it rather than invariably worse alternatives. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
