Pages in this topic: [Topic]
- Memory Management:
You have to be very careful while RetainingAndReleasing to maintain ThreadSafety. To be thread safe, code has to make proper use of MemoryManagement in order to be certain that there are no references to objects which have been deallocated, and no releasing of objects by something that does not own them.
In order to preserve ThreadSafety, you can send everything you use a retain message, you can employ an AutoReleasePool and AutoRelease objects, or you can use the concept of WeakReferences to avoid RetainCycles.
- Locking objects:
Any time more than one thread accesses the same piece of data, that data must have some sort of lock applied to it, to prevent its value from being changed by one thread behind the back of another thread. See NSLock and its variants for tools to use in this situation. http://goo.gl/OeSCu
see also: CanTwoThreadsLockFocusOnTheSameView
- Thread safety of Apple's classes:
I have heard conflicting reports about the thread safety of the AppKit -- specifically, whether or not AppKit classes can be called from any thread other than the main thread. Some people have emphatically told me that it should not be done. However Apple's own documentation (/Developer/ADC Reference Library/documentation/Cocoa/Conceptual/Multithreading/Multithreading.html) suggests that is not necessarily true, although it remains somewhat ambiguous about what is and isn't possible.
I know for a fact that updating an NSTextView from a worker thread is unsafe. I know for a fact that working with icons (via NSWorkspace) in a worker is unsafe. I strongly suspect all menu operations are unsafe. Pending more complete documentation, I'd assume everything in AppKit is unsafe unless told otherwise (such as drawing and other topics touched on in the release note).
- Inter-Thread communication via NSConnection:
You can use NSConnection to communicate across threads safely. I have found this to be really convenient, but with some performance impact. But it's worth a try.
Find some trivial examples in:
You can use its code snippets to implement a simple client/server that uses mach messages to pass messages. To aid development, build the server into an Application (so AppKit manages the run loop for you) and create a command-line tool client or an Application client, whichever is easier. That should give you a leg-up on writing us some sample code ;-).
When making your app thread-safe, NSConnection.html again suggests using mach-ports, and illustrates exactly how to do it. I was able to just plug it into an existing project of mine.
There are some less-elementary examples of using DO on TCP/IP on the system here:
Thomas Lachand-Robert also wrote a whole page about communication between threads, and in particular to AppKit: http://lachand.free.fr/cocoa/Threads.html Don't hesitate to send him any suggestions for additions or changes.
This recent post from MacOsxDev may also be of interest:
From: Toby Paterson <email@example.com>
Subject: Inter-thread messaging: a solution
The topic of how to communicate between two threads efficiently has come up a number of times while I've been on this list. I've written some code to facilitate this and am making it available for your use and abuse.
The model expects that you have one or more worker threads that need to post information back to the main, UI thread, though it can be used to communicate with any thread running a run loop. It takes the form of categories on NSObject and NSNotificationCenter to allow you to invoke methods and post notifications in a specific thread:
[master performSelector:@selector(workerDone:) withObject:self inThread:mainThread];
[[NSNotificationCenter defaultCenter] postNotificationName:kSomethingHappened object:self inThread:mainThread beforeDate:[[[NSDate]] distantFuture]];
The implementation uses NSPortMessages to marshall the message to the target thread. It's more light-weight than DO - NSPortMessage and NSPort are a fairly thin veneer on top of mach messaging - but not nearly as general. Make sure you read the comments in the header for some caveats of the argument marshalling.
I'm releasing this code in to the public domain: use it; modify it; ship it in free or commercial software; just don't expect any support nor assign to me any blame if using this code causes you any mental or physical harm. Have fun.
I have made a utility class, FDObjectiveMethod, that allows you to treat a method as an object. You initialize it with a complete (and that part is important, because if it's incomplete, you'll get errors) NSInvocation, and then start it with the -execute method. You can halt it part way through with the -stopExecution method.
It runs the invocation in a separate thread, so you don't have to worry about that.
Just starting some rewriting. -- KritTer