Re: Thread issue - sure can use some help
Re: Thread issue - sure can use some help
- Subject: Re: Thread issue - sure can use some help
- From: John Draper <email@hidden>
- Date: Sat, 08 Apr 2006 17:00:54 -0700
Jeff Moore wrote:
On Apr 7, 2006, at 5:10 PM, John Draper wrote:
Jeff Moore wrote:
The crash looks to me like your thread is trying to message a bad
ObjC object. That implies some kind of data coherency issue in
your code. My guess is that you have one thread that is disposing
of an object while another thread is trying to use it.
yes - That is what I suspect, but I'm clueless as to how to deal
with it. Especially since I'm using
a thread from some outside non-mac code I'm using (JRTPLIB).
Although it uses the POSIX
pthreads, somehow I have to get it to "know about" the
MTCoreAudio. If you've seen my
earlier postings, I asked the group about using the @synchronize
directive, but don't know
how to use it, or how much latency it's going to introduce in the
program.
I'm not an ObjC expert, but I think the @synchronize directive works
more or less like synchronized methods in Java do.
Many people have mentioned this, but when I ask them about how to use
it, I just get blank stares.
I found just ONE technote that mentioned it, but no mention about the
object I pass it and
what it does. Is this the object that has the data structures I'm to
protect? or is this
the object pointing to the class I'm in when I call it?
The hang is a deadlock of some flavor. This means that one thread
is blocking while holding onto a lock that is blocking the other
thread while it tries to acquire the lock.
yes - I suspect this to be the case, but I'm clueless as to how to
deal with it, and this is why I'm
willing to share the code and have others (who have the time) to
review it, but privately (off the list)
of course. And if others are interested, I'll be happy to post the
fix if I ever find it.
It's easy to pick out the blocked threads using the output of the
sample tool.
Easy for you perhaps!!! but not for me. Were you referring to the
thread viewer program?
If I were to ship you with the executeable and you run it with the
thread viewer, do you
think you might be able to see what's going on?
I would have to closly collaborate with you on this test if you want to
help me with it.
iChat and Skype would be a good venue for this. The application
accesses our internal
SIP server, so would have to set this up in advance for the test.
Testing this has been
a real headache... Often times I don't have access to a WinBlows
machine to test this
with. I'm porting a WinBlows app to the Mac.
From there, it's generally pretty easy to identify what locks and
code paths are involved in the dead lock.
It is? Really? Could you show me how? I try to figure this out on
my own, and I just cannot seem
to find enough information to help me come to a sucessful conclusion.
Yea I know, "Welcome to mac
Programming" :-)
I remember running the program... I didn't see any of the colours that
showed up as a Locked
thread. Lots of them "jumping around" in real time.
Both problems are pretty basic parallel programming problems that
unfortunately, have no set answers.
yes - and I'm not a systems kernal programmer and not familiar with
multi-threading concepts...
That's cool. If you are looking for books on the topic, I'd start
with David Butenhof's "Programming with POSIX Threads".
I'm ordering it today - I hope it's not as rare as the "Programming in
UNIX Sockets" was. I did a lot
of research on the web on Posix threads already, and the JRTPLIB has
jthread and jmutex, and
the JRTPLIB uses it, but for it's OWN purposes, and it wouldn't "know"
about any other threads
known to have been derived from Cocoa classes, even though the Cocoa
NSThread does call and
use the Posix pthread code. So somehow my mutex must be setup to "know"
about the MTCoreAudio?
Not only is it a great reference to the pthread API, but it is chock
full of advice on using the API as well as general knowledge about
parallel programming.
Yea - I found a lot of material on it, and I hope to believe I
understand it fairly well, it's just that
the Mutex used by the RTP stack is a seperate library and it knows
nothing of Cocoa Threads.
So the main problem might be to somehow make a Mutex know about a
NSLock? I just don't know
yet. I'm still waiting for Mike Thornburg (author of MTCoreAudio to
return my Email - it's
been over 10 days and he hasn't replied to my questions about
MTCoreAudio), and I don't think
anyone in this group is using it, or I would have heard from them by now.
I have also been reading Gregory Andrews' "Concurrent Programming:
Principles and Practice" again lately. This book is much more into
the theoretical side of things. It spends a good deal of text
teaching the concepts through logic proofs as opposed to using more
practical examples in C.
I lack the theoritical knowledge of the fine points of programming. Due
to circumstances beyond my
control, my college education was sadly interrupted about 3/4th the way
through.
Still, I've been able to apply it's lessons to my everyday work. I
particularly like the sections that detail the history of the
development of the various techniques. For instance, I didn't know
why the two semaphore operations were always notated with P and V
before reading this book.
I have no idea what you are talking about when you mention "P" and "V"
above...
The solution is going to be totally driven by the context. You
need to look very closely at how the various threads interact with
your data and design a locking solution that ensures that things
like this don't happen while at the same time allowing the code to
still be able to satisfy the real time demands of the audio system
(ie. make the deadlines and don't block the IO thread, ever).
Yes - I've been working on that, but cannot do that because I don't
have the source of Cocoa tools,
and I still haven't been able to get any response from the
MTCoreAudio framework author.
You can still get an idea of what threads are doing what using the
tools on the system.
Still trying to get this "idea" you are talking about.
The sample tool I mentioned is one good tool for the job, but Shark
is also eminently helpful, especially when using the System Trace
profile.
What "tool" were you referring to when you mentioned it in the sentence
above?
yea - I'll have shark up and running soon. I just got it.
But let me ask this.... lets say there IS object contention in
MTCoreAudio, and I assume such,
is there a way I can still keep this from happening. I was referred
to the @synchronize directive,
but not even ONE single example of how to use it....
the source for MTCoreAudio is on the net.
Sure you can. You are totally in control here since you are the one
that is writing the code that glues the SIP library to the
MTCoreAudio library. You can always use your own locks to manage the
synchronization.
Perhaps so - I just dont know how.
The first step for you will be to identify the causes of the hangs
and crashes using the tools.
That's been my MAIN problem, how do I do that?
From there you can formulate a plan to deal with it.
I had thought it was the MTCoreAudio's receiveQueue NSMuteableArray object.
I just don't know how to use @Synchronize and cannot find any examples
of code using it.
They are not clear on what this Object should be... is it the object
of the class from
which I want to synchronize, or is it the object in the MTCoreAudio (IE:
the NSMuteableArray).
Nobody has come forth to help me in this. Like I said earlier, I can
ship you the project
(but to use it - you need X-code 1.5). Or I can ship you just the
relevant modules including
the MTCoreAudio I'm using if you care to take a look at it, and if you
decide to actually
look at it, that I would be given the opportunity to talk to you in
real time in either iChat
or Skype. I would prefer that, then to send you everything, it's quite
large.
My user ID on both of them is "jdcrunchman". Could we do this? I'm not
expecting you to spend a lot of time on this, just point out what I
have to do to change
it to work.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden