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: Jeff Moore <email@hidden>
- Date: Mon, 10 Apr 2006 12:19:47 -0700
This is getting silly. I can't even begin a discussion on possible
solutions to your dilemma unless you have the technical background to
understand and implement any advice I might give. How can we discuss
the usage of mutexes, semaphores and predicates, when you don't know
what a mutex, semaphore, or predicate is?
It is way beyond the scope of this mailing list to teach the basics
in parallel programming. I don't really seen any point in continuing
this discussion until you have some actual, specific technical
questions that pertain to audio on OS X.
On Apr 8, 2006, at 5:00 PM, John Draper wrote:
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.
_______________________________________________
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