site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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 <steve@cs.washington.edu> wrote: So I'm beginning to realize. _______________________________________________ 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... 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. 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. This email sent to site_archiver@lists.apple.com