Re: Is Apple's singleton sample code correct?
Re: Is Apple's singleton sample code correct?
- Subject: Re: Is Apple's singleton sample code correct?
- From: Shaun Wexler <email@hidden>
- Date: Fri, 2 Dec 2005 10:48:53 -0800
On Dec 2, 2005, at 7:26 AM, Dietmar Planitzer wrote:
I must say I'm quite a bit surprised at how this discussion has
been going on. I'm especially surprised when I consider on one hand
that the OP, as far as I remember, wondered why the singelton
sample code is overriding the various reference counting methods
and that he was seeking an answer to this question. On the other
side I'm surprised by the fact that as far as I can tell not too
many people participating in this discussion seem to have actually
read the sample code.
I encourage everyone who reads this lines to take a close look at
the sample code which can be found here: <http://
developer.apple.com/documentation/Cocoa/Conceptual/CocoaObjects/
Articles/CreateSingleton.html>. When you do this you will notice
that the code as it is written there contains at least three quite
obvious bugs.
At this point the obvious question is: what about the reference
counting methods ?
The answer is simple: overriding them is unnecessary and does not
serve a real technical purpose. In fact, by overriding them the
sample code has hidden the various memory management bugs it has
and additionally, and even worse, it has made it impossible to find
memory management bugs in the application code which is dealing
with the singleton. This however can easily become a problem on the
day that the singleton is replaced with a standard object because
we may need to add another feature to the application that makes it
impractical to retain the singleton aspect of the class which has
so far been implemented as a singleton.
Yes, there are three obvious bugs, but they aren't in the ref-
counting methods. Ref-counting has been REMOVED from the singleton
class, so "standard Cocoa" rules don't apply [internally] because the
object has become immortal. The sample code is correct.
The first bug is that if -dealloc is sent to it directly, it will be
freed, so -dealloc must be overridden to become a NOP, ala -release.
That method should be added to the sample code.
The second bug is that the recursive mutex @synchronized(self) needs
to be @synchronized([MyGizmoClass class]) in both class methods,
because the static variable sharedGizmoManager is what the mutex has
to protect, because two subclasses created simultaneously on two
threads permits a race situation. The sample code should be updated
and documented to reflect this.
The third bug is that the design is messy, and doesn't allow
subclassing. Both +sharedManager and +allocWithZone: allow
assignment of sharedGizmoManager, and it reassigns it (and hits the
lock twice) when instantiated properly. According to the last
comment, this is intended to permit optional usage. The sample code
should be augmented with 2 or 3 other singleton designs, with
examples. Also, the +sharedManager methods should be more efficient
because they are messaged often, and entering the mutex should be
avoided if the static var is valid, plus an early exit minimizes the
cache hits to load the unnecessary code each use.
+ (MyGizmoClass*)sharedManager
{
if (sharedGizmoManager) {
return sharedGizmoManager;
}
@synchronized(self) {
if (sharedGizmoManager == nil) {
sharedGizmoManager = [[self alloc] init];
}
}
return sharedGizmoManager;
}
Really, this thread is entirely too silly, but with all of the C++/
WIN switchers to come, it's better to explain it correctly in the
archives, or we'll have to go thru it again and again.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"Problems cannot be solved by the same level of thinking that created
them." - Albert Einstein
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden