Re: Thread safety issue...
Re: Thread safety issue...
- Subject: Re: Thread safety issue...
- From: John Draper <email@hidden>
- Date: Thu, 06 Apr 2006 03:45:28 -0700
Christian Stieber wrote:
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.
And how would I do this... Can you help me with this? I'm currently
using an RTP stack I got from the net, and sucessfully got it ported to the
Mac. It works... the VIOP works, it passes audio over the net in
both directions, then it stops. Sometimes it crashes, other times it
hangs up in a Mutex.lock()
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.
It would be very difficult because it would lock up any other actions
like allowing the user to do things while "talking" with the remote user.
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:
,
That URL is unreachable - it is too long and may have been munged by
your mailer.
Were you just referring to the NSThread documentation? I read it already,
and I cannot use it in the RTP stack, as it has it's OWN threading code, and
it is very tightly integrated into the JRTPLIB.
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 :-)
NSThread is in Cocoa, if that URL was referencing it.
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.
Do you think you might have time to help me in this? I have No clue
how to make this proxy object you were mentioning.
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...
THAT's the problem - it IS very very time critical. I'm slicing up
audio frames every 40 ms. Everything has to run asynchronously.
As for making proxy objects: Apples documentation on the matter
is rather flawed;
Not surprisingly. I never ran into ANY documentation explaining
Proxy objects. I never even Heard of them until you mentioned it.
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).
I think the MTCoreAudio uses the ForwardInvocation. Here is a snippit
of code it uses.
- (void) dispatchIOProcWithTimeStamp:(const AudioTimeStamp *)inNow
inputData:(const AudioBufferList *)inInputData inputTime:(const
AudioTimeStamp *)inInputTime outputData:(AudioBufferList *)outOutputData
outputTime:(const AudioTimeStamp *)inOutputTime
{
if ( isPaused )
return;
if (myIOProc)
{
(void)(*myIOProc)( myDevice, inNow, inInputData, inInputTime,
outOutputData, inOutputTime, myIOProcClientData );
}
else if (myIOInvocation)
{
[myIOInvocation setArgument:&inNow atIndex:3];
[myIOInvocation setArgument:&inInputData atIndex:4];
[myIOInvocation setArgument:&inInputTime atIndex:5];
[myIOInvocation setArgument:&outOutputData atIndex:6];
[myIOInvocation setArgument:&inOutputTime atIndex:7];
[myIOInvocation invoke];
}
}
Is this what you are talking about?
John
_______________________________________________
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