Re: Thread critical sections
Re: Thread critical sections
- Subject: Re: Thread critical sections
- From: Steve Checkoway <email@hidden>
- Date: Fri, 28 Oct 2005 22:36:00 -0700
On Oct 28, 2005, at 9:42 PM, Kevin Elliott wrote:
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.
Actually, I've never used that api, it's just what turned up when I
searched for thread critical section on apple's site.
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.
Given the length of time that it would need to be running at such a
high priority, I would guess (although this is untested and I might
be totally wrong here) that it wouldn't cause much of an issue. File
IO is so insanely slow anyway. Other real time threads suffering is a
very serious issue though.
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).
This needs to be done quite often, 60 or so times per second. The
thread does a fair bit of work before it blocks again. It's a tiny
fraction of that computation that needs to be done as quickly as
possible.
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.
No, we're not sure if it's a real problem on OS X. As I understand
it, it was a problem on Windows. You are absolutely right that I
should check to see if it is a real problem. I was hoping that there
might be some "magical" fix, as there was on the Windows code (don't
ask me why or how, I didn't write any of that code), that had no
showstopping drawbacks. Sort of a, "if it's a real problem, this will
fix it, if it's not a problem, then this does no harm."
I'm not sure I see how the app being well factored would cause this
to not be a problem. It seems to be a function of the scheduler and
how many threads are running.
- Steve
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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