Re: Thread safety issue...
Re: Thread safety issue...
- Subject: Re: Thread safety issue...
- From: Christian Stieber <email@hidden>
- Date: Thu, 06 Apr 2006 09:43:31 +0200
At 18:47 05.04.2006 -0700, John Draper wrote:
So - I have this MTCoreAudio framework - which is probably NOT thread
safe, and without it,
I can never hope to deliver my App on time, so how can I make something I
know nothing about
thread safe?
What I did to make classes that I don't know anything about "thread safe",
at least as much as I can tell, is by setting up a "proxy" class that
passes all methods to the real object, enclosed by a [Mutex lock]/
[Mutex unlock]. I don't use the @synchronize --- it seems an obscure
thing, and I don't like that.
In general, however, one should try to simply run the methods on the
main thread, since you really don't know what the stuff does, and
some things are not allowed to run in threads (GUI related things
in particular seem to be restricted in that matter). In particular,
there is a lot of classes that I don't really trust in terms of
thread safety, so often I just make my own just to be sure.
If I really need to run "do not run in threads" stuff from threads I
use a proxy object as well that is message-passing the NSInvocation
to the main thread and waiting for the result --- that was before I
discovered
-<http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSThread.html#method$NSObject(NSMainThreadPerformAdditions)-performSelectorOnMainThread$withObject$waitUntilDone$modes$>performSelectorOnMainThread<http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSThread.html#method$NSObject(NSMainThreadPerformAdditions)-performSelectorOnMainThread$withObject$waitUntilDone$modes$>:withObject:waitUntilDone:modes:
,
which I believe exists on Cocoa as well. Just found that yesterday,
though, so the code where I'm using it hasn't run yet. I just assume
it works as advertised :-)
To use this in a generic way you still have to make a proxy object
(the performmSelector() methods only take selectors with one
argument -> just invoke an invocation method to invoke the
invocation... any idea how to get more "invoke"s into a sentence?),
but I *presume* it's more efficient than the stupid NSMessagePort
stuff I've been using so far since it can just link the thing into
the "perform selector" queue using whatever internal implementation
details it knows on how to access it and wake up the runloop. If
it works I'll probably remove most of my previous NSMessagePort-based
communications, since I used these only as signals to wake up the
runloop.
Keep in mind that this introduces a lot of latency on method calls,
so if anything is time critical, don't run it from a thread like
this. Run the whole critical code segment on the main thread...
As for making proxy objects: Apples documentation on the matter
is rather flawed; in addition to implementing the forwardInvocation
method, your proxy also needs to understand methodSignatureForSelector.
I'm also implementing respondsToSelector, but I don't remember
whether that's actually required (don't think so).
Christian
_______________________________________________
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