Re: Wait Queues
Re: Wait Queues
- Subject: Re: Wait Queues
- From: Vivek Balasubramanyam <email@hidden>
- Date: Wed, 5 Mar 2003 18:24:02 -0800
This makes sense, but I just have one more question. If I'm not
allocating a wait_queue, then I suppose I need an event_t to wait on
and signal. But, event_t is just a void*, so I'm not sure what it
actually should be.
On Wednesday, March 5, 2003, at 01:00 PM, Jim Magee wrote:
On Wednesday, March 5, 2003, at 03:38 PM, Vivek Balasubramanyam wrote:
I am definitely not giving up the CPU, although I expected that the
assert_wait() function would put my thread to sleep. Are you saying
that I need to call thread_block() in addition to assert_wait() in
order to fall asleep?
Correct. In Mach, blocking within the kernel is a two step process.
You assert your intention to wait on a particular event, and then you
block. Normally, you would unlock whatever you were using for
synchronization after calling assert_wait() and before giving up the
CPU (with thread_block()).
This two stage approach has several advantages:
1. It allows you to use whatever form of synchronization you want
(because you do the unlocking manually between the assert_wait() and
the thread_block().
2. It also allows you to check the return from assert_wait() to see
if you really should block. For instance, you may be aborted because
of a pending signal or thread termination, and the wait may have been
interruptible, in which case the assert_wait() didn't have effect. So,
no need to give up the CPU, just return the interrupted status so you
can get to your signal handler quickly.
3. Once you unlock, but before you try to give up the CPU, the event
may get posted (by another thread on another CPU, by a thread that
preempts you on this CPU, or by an interrupt handler). By giving a
window for this to happen before you commit to giving up the CPU, you
may avoid unnecessary context switches.
There isn't a specific need to use wait queues over any other kind of
synchronization, since only one thread is ever in the queue. But I
do need to use something that will let this thread sleep until a
separate thread sends a wakeup signal (when the buffer goes from
empty to non-empty).
Note that you don't have to allocate your own wait_queues. There are
a standard set of them for the system. If you just call
assert_wait(), your event will be hashed to select one of the standard
wait_queues to put you in. You only need your own wait_queue if you
are going to use the wait_queue's native locking as your wider
synchronization primitive (not available outside the osfmk component,
but used by both Mach message queues, semaphores, and locksets) or if
you need to manage sets of related waiters and event sources (like
Mach portsets or BSD select sets, etc...).
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.