site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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. - Steve _______________________________________________ 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 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. 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? smime.p7s