This is a somewhat older but quite interesting thread - nonetheless I felt the
final conclusion was still too vague.
So, I did my best to put up a simple "worst case" sample and tried to trick
dispatch_once into a race. But I failed. That is, dispatch_once was doing what
one would like to expe
On Sat, 08 Dec 2012 16:45:37 -0800, Greg Parker said:
>Source: me, the author of the current @synchronized implementation.
>@synchronized performs the same synchronization as a pthread mutex.
Wow, this is just like that scene in the Woody Allen movie where Marshall
McLuhan shows up!!! :) m.
--
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 exampl
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 workar
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
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
On Sat, Dec 8, 2012, at 05:27 PM, Richard Heard wrote:
> Greg,
>
> So, from what you are saying, either of these snippets should be valid,
> right?
>
> > +(id)sharedInstance{
> > static id _sharedInstance = nil;
> >
> > if (!_sharedInstance){
> > @synchronized([self class]){
> >
On Dec 8, 2012, at 18:51 , Greg Parker wrote:
> Use dispatch_once(). It is shorter, simpler, and more obviously correct. The
> memory barrier implementation may also be correct, but why take the risk?
What about for similar non-static properties?
--
Rick
_
On Dec 8, 2012, at 5:27 PM, Richard Heard wrote:
> Greg,
>
> So, from what you are saying, either of these snippets should be valid, right?
>
>> +(id)sharedInstance{
>> static id _sharedInstance = nil;
>>
>> if (!_sharedInstance){
>> @synchronized([self class]){
>>
Greg,
So, from what you are saying, either of these snippets should be valid, right?
> +(id)sharedInstance{
> static id _sharedInstance = nil;
>
> if (!_sharedInstance){
> @synchronized([self class]){
> if (!_sharedInstance){
> id sharedInstance = [[s
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
Speaking of Double-Checked Locking, there is this interesting article from
Scott Meyers and Andrei Alexandrescu, written in 2004, which states:
This article explains why Singleton isn’t thread safe, how DCLP attempts to
address that problem, why DCLP may fail on both uni- and multiprocessor
ar-
On Dec 8, 2012, at 1:17 PM, 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 be essentially useless for its intended purpose.
>>
>
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 be essentially useless for its intended purpose.
By the way, you're wrong about this too. All @synchronized does
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 be essentially 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 do
On Dec 8, 2012, at 10:06 AM, Steve Sisak wrote:
> At 8:35 AM -0800 12/8/12, Kyle Sluder wrote:
>> On Dec 7, 2012, at 8:38 PM, Marco S Hyman wrote:
>>
>>> On Dec 7, 2012, at 8:18 PM, Steve Sisak wrote:
>>>
I'm interested if there are an any issued I'm missing in the Obj-C,
@synchron
At 8:35 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 7, 2012, at 8:38 PM, Marco S Hyman wrote:
On Dec 7, 2012, at 8:18 PM, Steve Sisak wrote:
I'm interested if there are an any issued I'm missing in the
Obj-C, @synchronized(self), instance variable case.
Your pattern can fail if this l
On Dec 7, 2012, at 8:38 PM, Marco S Hyman wrote:
> On Dec 7, 2012, at 8:18 PM, Steve Sisak wrote:
>
>> I'm interested if there are an any issued I'm missing in the Obj-C,
>> @synchronized(self), instance variable case.
>
>
> Your pattern can fail if this line
>_someDictionary = temp;
On Dec 7, 2012, at 10:18 PM, Steve Sisak wrote:
> At 8:57 PM -0600 12/7/12, Ken Thomases wrote:
>> > the outer if avoids the overhead of @synchronized if _someDictionary is
>> > already created -- this is just an optimization
>>>
>>> the inner if is necessary to resolve the race condition if mul
On Dec 7, 2012, at 8:18 PM, Steve Sisak wrote:
> I'm interested if there are an any issued I'm missing in the Obj-C,
> @synchronized(self), instance variable case.
Your pattern can fail if this line
_someDictionary = temp;
isn't atomic.
__
At 8:57 PM -0600 12/7/12, Ken Thomases wrote:
> the outer if avoids the overhead of
@synchronized if _someDictionary is already
created -- this is just an optimization
the inner if is necessary to resolve the race
condition if multiple threads make it past the
outer one
This is a classic
On Dec 7, 2012, at 8:01 PM, Steve Sisak wrote:
> Here's what I usually do:
>
> assume that _someDictionary is an instance variable initialized to nil and
> never changed once initialized to non-nil
>
> - (NSDictionary *)someDictionary;
> {
> if (!_someDictionary)
> {
>@synchronized (self)
At 7:56 PM +0700 11/12/12, Gerriet M. Denkmann wrote:
- (NSDictionary *)someDictionary;
{
static NSDictionary *someDictionary;
static dispatch_once_t justOnce;
dispatch_once( &justOnce, ^
{
// create a temp dictionary (might take som
On Dec 7, 2012, at 2:04 PM, Ken Thomases 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 a
On 12 Nov 2012, at 20:45, Greg Parker wrote:
>
>
> There is something special about statically-allocated memory.
> Statically-allocated memory has always been zero for the life of the process.
> Dynamically-allocated memory may have been non-zero at some point in the past
> (i.e. if it was
On Dec 7, 2012, at 3:08 PM, Greg Parker wrote:
> On Dec 7, 2012, at 7:03 AM, Jeremy Pereira wrote:
>> On 12 Nov 2012, at 20:45, Greg Parker wrote:
>>> There is something special about statically-allocated memory.
>>> Statically-allocated memory has always been zero for the life of the
>>> proc
On Dec 7, 2012, at 7:03 AM, Jeremy Pereira wrote:
> On 12 Nov 2012, at 20:45, Greg Parker wrote:
>> There is something special about statically-allocated memory.
>> Statically-allocated memory has always been zero for the life of the
>> process. Dynamically-allocated memory may have been non-ze
On Nov 12, 2012, at 8:36 AM, Ken Thomases wrote:
> Far be it from me to discourage people from paying attention to the docs, but
> I'm pretty sure that the docs are excessively restrictive in this case.
>
> From working with similar constructs in other APIs, I believe the actual
> requirements
On Nov 12, 2012, at 8:41 AM, Joerg Simon wrote:
> On Nov 12, 2012, at 3:33 PM, Tom Davie wrote:
>
>> On 12 Nov 2012, at 14:18, Joerg Simon wrote:
>>
>>> You can use dispatch_sync. The blog post of oliver dobnigg (cocoanetics)
>>> summs that up quite nicely:
>>> http://www.cocoanetics.com/2012
As you can read in the blog too, the developer documentation of dispatch_once
states:
"The predicate must point to a variable stored in global or static scope. The
result of using a predicate with automatic or dynamic storage is undefined."
so, no, you can not. Actually it works most of the tim
On 12 Nov 2012, at 14:18, Joerg Simon wrote:
> You can use dispatch_sync. The blog post of oliver dobnigg (cocoanetics)
> summs that up quite nicely:
> http://www.cocoanetics.com/2012/02/threadsafe-lazy-property-initialization/
Or you can use dispatch_once, but make sure the once token is an i
You can use dispatch_sync. The blog post of oliver dobnigg (cocoanetics) summs
that up quite nicely:
http://www.cocoanetics.com/2012/02/threadsafe-lazy-property-initialization/
Cheers, Jörg
On Nov 12, 2012, at 2:44 PM, Tom Davie wrote:
>
> On 12 Nov 2012, at 13:39, Marco Tabini wrote:
>
>>>
On 12 Nov 2012, at 13:39, Marco Tabini wrote:
>> This is completely the wrong way to implement a property. The static
>> variable will be shared between all instances. Here's how you should be
>> doing a lazy loaded var:
>>
>> @implementation MyClass
>> {
>> NSDictionary *_someDictionary
> This is completely the wrong way to implement a property. The static
> variable will be shared between all instances. Here's how you should be
> doing a lazy loaded var:
>
> @implementation MyClass
> {
>NSDictionary *_someDictionary
> }
>
> - (NSDictionary *)someDictionary
> {
>stat
On 12 Nov 2012, at 12:56, "Gerriet M. Denkmann" wrote:
> I have a property:
>
> @property (readonly) NSDictionary *someDictionary;
>
> This property should be computed on demand, and should be accessible by
> several threads.
>
> My current implementation is:
>
> - (NSDictionary
Looking at the docs, dispatch_once takes care of the synchronization for you:
https://developer.apple.com/library/mac/ipad/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html
It should therefore be thread safe to use without any additional
synchronization code.
Se
I have a property:
@property (readonly) NSDictionary *someDictionary;
This property should be computed on demand, and should be accessible by several
threads.
My current implementation is:
- (NSDictionary *)someDictionary;
{
static NSDictionary *someDictionary;
st
37 matches
Mail list logo
