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
On Sat, 08 Dec 2012 16:45:37 -0800, Greg Parker gpar...@apple.com 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
Le 9 déc. 2012 à 02:27, Richard Heard heard...@gmail.com 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 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
On Dec 9, 2012, at 6:53 AM, Ken Thomases k...@codeweavers.com 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
On Dec 9, 2012, at 10:37 AM, Kyle Sluder wrote:
On Dec 9, 2012, at 6:53 AM, Ken Thomases k...@codeweavers.com 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
On Dec 7, 2012, at 8:38 PM, Marco S Hyman m...@snafu.org wrote:
On Dec 7, 2012, at 8:18 PM, Steve Sisak sgs-li...@codewell.com 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
At 8:35 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 7, 2012, at 8:38 PM, Marco S Hyman m...@snafu.org wrote:
On Dec 7, 2012, at 8:18 PM, Steve Sisak sgs-li...@codewell.com wrote:
I'm interested if there are an any issued I'm missing in the
Obj-C, @synchronized(self), instance variable
On Dec 8, 2012, at 10:06 AM, Steve Sisak sgs-li...@codewell.com wrote:
At 8:35 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 7, 2012, at 8:38 PM, Marco S Hyman m...@snafu.org wrote:
On Dec 7, 2012, at 8:18 PM, Steve Sisak sgs-li...@codewell.com wrote:
I'm interested if there are an any
On Dec 8, 2012, at 10:06 AM, Steve Sisak sgs-li...@codewell.com 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
At 10:24 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 8, 2012, at 10:06 AM, Steve Sisak sgs-li...@codewell.com 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.
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 sgs-li...@codewell.com wrote:
Further, if writes were not complete at the end of the block, the
construct would be essentially useless for its intended
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
On Dec 8, 2012, at 11:17 AM, Steve Sisak sgs-li...@codewell.com wrote:
At 10:24 AM -0800 12/8/12, Kyle Sluder wrote:
On Dec 8, 2012, at 10:06 AM, Steve Sisak sgs-li...@codewell.com wrote:
Further, if writes were not complete at the end of the block, the construct
would besentially useless
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 = [[super
On Dec 8, 2012, at 5:27 PM, Richard Heard heard...@gmail.com 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 gpar...@apple.com 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 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]){
if
On Dec 7, 2012, at 7:03 AM, Jeremy Pereira jere...@jeremyp.net wrote:
On 12 Nov 2012, at 20:45, Greg Parker gpar...@apple.com wrote:
There is something special about statically-allocated memory.
Statically-allocated memory has always been zero for the life of the
process.
On Dec 7, 2012, at 3:08 PM, Greg Parker wrote:
On Dec 7, 2012, at 7:03 AM, Jeremy Pereira jere...@jeremyp.net wrote:
On 12 Nov 2012, at 20:45, Greg Parker gpar...@apple.com wrote:
There is something special about statically-allocated memory.
Statically-allocated memory has always been zero
On 12 Nov 2012, at 20:45, Greg Parker gpar...@apple.com 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
On Dec 7, 2012, at 2:04 PM, Ken Thomases k...@codeweavers.com 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
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
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 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:18 PM, Steve Sisak sgs-li...@codewell.com 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.
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;
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.
On 12 Nov 2012, at 12:56, Gerriet M. Denkmann gerr...@mdenkmann.de 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:
-
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
{
static
On 12 Nov 2012, at 13:39, Marco Tabini mtab...@me.com 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
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 tom.da...@gmail.com wrote:
On 12 Nov 2012, at 13:39, Marco
On 12 Nov 2012, at 14:18, Joerg Simon j_si...@mac.com 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
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
On Nov 12, 2012, at 8:41 AM, Joerg Simon wrote:
On Nov 12, 2012, at 3:33 PM, Tom Davie tom.da...@gmail.com wrote:
On 12 Nov 2012, at 14:18, Joerg Simon j_si...@mac.com wrote:
You can use dispatch_sync. The blog post of oliver dobnigg (cocoanetics)
summs that up quite nicely:
On Nov 12, 2012, at 8:36 AM, Ken Thomases k...@codeweavers.com 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
36 matches
Mail list logo
