Re: Thread critical sections
Re: Thread critical sections
- Subject: Re: Thread critical sections
- From: Kevin Elliott <email@hidden>
- Date: Fri, 28 Oct 2005 21:42:00 -0700
On Oct 28, 2005, at 9:20 PM, Steve Checkoway wrote:
On Oct 28, 2005, at 8:00 PM, Solra Bizna wrote:
On 10/28/05, Steve Checkoway <email@hidden> wrote:
Is there a way to get behavior similar to Carbon's Thread Manager
functions ThreadBeginCritical() and ThreadEndCritical() using
pthreads
or mach threads?
I think this is impossible with pthreads.
So I'm beginning to realize.
Let me elaborate further on what I'm trying to do so that maybe
someone will have a suggestion for how to proceed.
Ideally, what happens is we are getting a current time stamp and then
asking the sound hardware (or its driver) for it's position. The
example that was given to me by another programmer is, "we can say
'the sound was at 33.5secs at 5:33:20pm.' "
This is not an issue with multiple threads executing the code at the
same time or with multiply threads reading and writing data at the
same time. The issue is if we get the current time and then we are
preempted before we get the time from the sound hardware, it
introduces errors. Millisecond timing is of utmost importance so the
errors introduced by this are potentially nontrivial.
Hmm... Well, just to throw a little gasoline on the fire, your old API
wouldn't help either. On OS9 you could get away from this because you
wouldn't get preempted, but under OSX their is no such guarantee. For
your purposes it doesn't matter if the OS preempts you or a thread from
within your own app- either way your screwed.
One idea is to raise the priority of the thread to realtime for the
short time that this code is executing and then lower it back to its
old priority. Since this is expected to happen 60 times each second
(or so), will doing this cause undue strain for the scheduler that
would impact performance in other ways negating any benefits gained by
(hopefully) not being preempted during that short bit of time?
I don't think that'll work either. You can raise your pthread
priority, but I don't think it'll have a big enough effect to make that
much difference. You could become a true real time thread, but I have
done much with them. My understanding is that their are significant
restrictions on what you can do inside one, and that you need to pretty
careful. Real time threads can run at a high enough priority that they
can take priority over stuff like the file IO threads with all sort of
interesting consequences.
How often do you need to be doing this? My experience is that I/O
bound threads (or any thread that runs for short amounts of time and
blocks frequently) should get all the time they need. If your thread
blocks, does it's work, then blocks again it's very unlikely to be
blocked (as long as your not doing very much work).
The other thing to look at, is are you SURE this is a real problem?
The first thing I'd do is instrument up the code and start seeing how
often your getting preempted and having your time stamps broken. If
your app is well factored, I wouldn't think it would happen very often.
It might be a lot easier to grab a time stamp before and after and
throw away the sample if it's "damaged". I don't know if that would
work in you design or not.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden