Re: multiple threads mutex, unlocking order
Re: multiple threads mutex, unlocking order
- Subject: Re: multiple threads mutex, unlocking order
- From: Michael Smith <email@hidden>
- Date: Mon, 16 Jun 2008 09:18:56 -0700
On Jun 16, 2008, at 8:09 AM, Matt Connolly wrote:
Do the IOLock lock and unlock routines have to be called from the
same thread?
They should, yes.
If multiple threads are waiting on the IOLock, are they executed in
the order that they began waiting on the Lock?
No.
I'm looking for a way for a kernel task to wait for a user space
process to respond to a message.
This is generally a bad way to do things; you want the user process to
drive the messaging, not the kernel.
The underlying issue is that user processes are transient and
unreliable, so you need to behave correctly in the case where the
process fails to complete the work, or terminates while the work is in
progress.
IFF we assume that you have arranged for the user process to re-start,
you need to maintain queues of work items (in progress, waiting)
inside the kernel so that you can re-issue work to your user process
if it checks in after crashing. (And your work items need to be
devised such that they can safely be re-started).
Basically, I want to serialise things, so that if there are multiple
kernel threads sending to the user-space process, that they will
have their information processed, and be woken from their locks in
the correct order.
A better model is for the work items to be queued inside the kernel,
and for the user process to come along and pick up these work items as
it has resources available. As for "the correct order", since kernel
threads run concurrently with user threads, it is entirely your
responsibility to ensure ordering. You can use a global sequence
number, or sort the queue, or... there are many options depending
solely on what sort of ordering you're actually talking about.
HTH.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden