Answering the question with a warning… Be really careful with categories. While absolutely awesome (and one of the Objective-C features I love the most) categories can trip you up and cause your code to be cruftier and harder to maintain. * Up until …

Sometimes it’s best to just take shared data/code and put it into a different class, probably a custom singleton.

I like the pattern of having a class method to retrieve this stuff; let it do what it has to do lazily and handle synchronization. Alternately, make sure you deliberately get your initialization out of the way before you go spawning threads. Granted if you’re writing a library, you won’t have control over that. I personally like to avoid any kind of cyclical dependency between classes if at all possible, and stick with hierarchies; they’re easier to understand. I don’t so much like Bill’s turning a rule-of-thumb into a flat-out commandment, but whether or not you can (or should) do heavy lifting in +initialize, there’s probably no overwhelmingly convincing reason to do so.

That your code demonstrates that it is possible neither makes it correct, nor a good idea.

The bottom line is that +initializes are executed in arbitrary order and there are locks involved. If you cause complex sub-systems to be initialized from +initialize, your code will be fragile. It might work on your system, but not on a system with a larger/smaller number of cores. It might work on 10.5.8, but it might not on 10.6.0. Or it might break between 10.6.1 and 10.6.2. You are setting your code up to be dependent upon the +initialize of ever other class in your runtime being equally as well behaved and ordered as your code.

As I have said before, I have debugged many many situations where deadlocks have occurred because the developer was surprised by a sudden change in order of calls to +initialize or had naively introduced concurrency without realizing the subtle dependencies incurred by +initializes own locking implementation. In all cases, fixing the code moved the heavy lifting out of +initialize and into a much more controlled phase of application bringup.

The resulting code was less fragile, easier to maintain, and often eliminated various bits of locking infrastructure since the initialization work was triggered by passing through a very well known and controlled phase in application bringup.

There are much better phases in application launch or subsystem initialization to do this kind of work.

Do not do heavy lifting in +initialize. It is fragile, prone to concurrency bugs that are difficult to debug, and, in the near future, the documentation will emphatically indicate that you shouldn’t do so.

Thank you so much for updating your post to make my point for me.

Your code example is brilliant and illustrates my original comment perfectly. The problem here is in the implementation of the thread synchronization and has nothing to do with +initialize. Specifically, the use of a single NSLock in this design is fatally flawed. There are multiple methods using the same NSLock that can call each other recursively. That’s just wrong. Either they should be using separate locks, or an NSRecursiveLock, as appropriate.

Bad code can’t be use as an inditement against +initialize. You could add this code to any other set of method, class or instance, and have the same problem. The code example that should have been supplied should look something like this:

(note: code pasted into browser from a working Xcode project – might not run as copied)

@interface TestRunner : NSObject
+ (void)testThread:(id)ignored;
@end

@interface OneClass : NSObject
- (void)hello;
@end

@interface TwoClass : NSObject
@end

NSRecursiveLock *globalResourceLock = nil;
static OneClass *oneCircular;
static TwoClass *twoCircular;

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSLog(@"Hi!");

	globalResourceLock = [NSRecursiveLock new];
	for (int i=0; i<3; i++)
		[NSThread detachNewThreadSelector:@selector(testThread:)
								 toTarget:[TestRunner class]
							   withObject:nil];

	[NSThread sleepForTimeInterval:4.0];
	[globalResourceLock release];
	NSLog(@"Bye!");

    [pool drain];
    return 0;
}

@implementation TestRunner

+ (void)testThread:(id)ignored
{
	NSAutoreleasePool *pool = [NSAutoreleasePool new];

	NSLog(@"Thread starting...");
	OneClass *test = [[[OneClass alloc] init] autorelease];
	[test hello];

	[pool release];
}

@end

@implementation OneClass

+(void)initialize
{
	NSLog(@"%s started",__func__);
	[globalResourceLock lock];
	twoCircular = [TwoClass new];
	[NSThread sleepForTimeInterval:2.0];
	[globalResourceLock unlock];
	NSLog(@"%s done",__func__);
}

- (void)hello
{
	NSLog(@"%@ says hello",self);
}

@end

@implementation TwoClass

+(void)initialize {
	NSLog(@"%s started",__func__);
	[globalResourceLock lock];
	oneCircular = [OneClass new];
	[globalResourceLock unlock];
	NSLog(@"%s done",__func__);
}
@end

Here’s an application the spans multiple threads, started currently, that all initialize the same class, which initializes another class, that recursively uses the first class. This should be the perfect storm for +initialize to lock up our application. But, of course, it runs perfectly:

2009-09-12 09:19:20.798 InitializeTest[2180:10b] Hi!
2009-09-12 09:19:20.803 InitializeTest[2180:1403] Thread starting...
2009-09-12 09:19:20.803 InitializeTest[2180:1503] Thread starting...
2009-09-12 09:19:20.803 InitializeTest[2180:1603] Thread starting...
2009-09-12 09:19:20.804 InitializeTest[2180:1403] +[OneClass initialize] started
2009-09-12 09:19:20.805 InitializeTest[2180:1403] +[TwoClass initialize] started
2009-09-12 09:19:20.806 InitializeTest[2180:1403] +[TwoClass initialize] done
2009-09-12 09:19:22.806 InitializeTest[2180:1403] +[OneClass initialize] done
2009-09-12 09:19:22.808 InitializeTest[2180:1403]  says hello
2009-09-12 09:19:22.809 InitializeTest[2180:1503]  says hello
2009-09-12 09:19:22.809 InitializeTest[2180:1603]  says hello
2009-09-12 09:19:24.803 InitializeTest[2180:10b] Bye!

So I return to my original assertion: If +initialize is locking up your application, then your thread synchronization is flawed. Solving the problem by avoiding +initialize is simply avoiding the bug in your code. It doesn’t fix the real problem, and the problem has nothing to do with +initialize.

I didn’t suggest +load should be used. I stated the opposite, actually.

The issue is one of fragility. The example I gave is, as stated, contrived, but it is exactly the kind of pattern I have encountered time and again when finding and fixing bugs across many applications. In all cases, the “heavy lifting” was initializing some random sub-system that ended up spawning threads and/or making network connections. Totally bad design, for sure, but that wasn’t how the code started — it evolved into doing that as features were added to the subsystem.

The developer is far better off limiting +initialize to simple global state initialization and doing any sub-system initialization either at launch (if always needed) or on load of whatever needs said sub-system.

Therein lies the problem. +initialize starts out simple, doesn’t do heavy lifting, but then requires more and more stuff to be integrated into it as soon as you stop just doing simple stuff.

You may have caused deadlock issues using non-reentrant locks or through some other path, but the +initialize method is wrapped by a recursive lock that will not deadlock through circular references. Thus, class One’s +initialize can invoke class Two’s +initialize, which can safely use class One without any problems. Sample code would be easy to produce.

If you’ve encountered deadlocks in your +initialization code, then it’s due to a flaw in your thread synchronization design. It is not inherently a flaw in how +initialize is designed or implemented.

Your suggestion of using +load is far more dangerous and undesirable. Running code at +load, you may interact with classes that are not yet initialized. And worse, you push initialization code to application load time which simply slows launch times, rather that pushing time consuming initialization to +initialization time (or later) where it produces more efficient and responsive applications.

I’ve used +initialize effectively for many years and have never had a problem with it. I continue to recommend +initialize in all my books as the best solution to lazily initialize static/global class data structures.