Re: MPNotifyQueue takes 500,000 nsec (worst case)
Re: MPNotifyQueue takes 500,000 nsec (worst case)
- Subject: Re: MPNotifyQueue takes 500,000 nsec (worst case)
- From: Brian Willoughby <email@hidden>
- Date: Wed, 23 Oct 2002 14:39:18 -0700
[ How does pthread_cond_signal() manage not to block? It looks like
[ it calls semaphore_signal_thread() (in Mach) which is a kernel
[ call--and I thought all syscalls could possibly block the calling
[ thread.
Are you thinking of Mach behavior or Mac OS <= 9 behavior?
The cooperative multitasking of Mac OS Classic could switch programs during a
system call because that was the only way to do it. As far as I know, Mach
system calls only cause a task switch if they're scheduling I/O, messing with a
semaphore, or doing anything that might involve a polled loop in a lesser OS.
If the system call can implemented without waiting or looping, then Mach is
not going to use this as an opportunity to task switch. As I understand it,
Mach can interrupt a thread anywhere, without needing it to be during a system
call. That's not to say it doesn't help to call thread_yield() to smooth out
the multitasking and give a hint to Mach as to when it would be good to block a
thread. And, of course, if you signal a higher priority thread that is
waiting, you'll certainly be blocked by the higher priority thread during that
system call.
[ Do I have an over-simplified view of what's really happening?
[ (Probably!)
He, he. I probably have an over-simplified view, too. I'm not sure I know
exactly how everything works, so I welcome anyone who can clarify any of my
mistakes above.
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.