site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 28, 2005, at 9:42 PM, Kevin Elliott wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com 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 smime.p7s