Thanks, Mike.
In my application, the kernel has to initiate the messaging, since it's intercepting an event in the kernel space, but the user-space process is responsible for handling it. (to reduce code in kernel, and for higher level os interfaces).
The user-space connects via a IOUserClient sub-class. Only when this sub-class is instantiated does the driver activate. So, yes, I'm checking what to do if the user-space process crashes out -> the IOUserClient sub-class will get a clientDied message, and the rest of the driver deactivates.
Semaphores seem like the go. But I read somewhere that when a semaphore is signalled, that the waiting thread will not activate immediately - I was hoping that I could get this to happen to reduce latency.
Alternatively, mach messaging might be best. In both of these cases, you can do a timed wait, so if the user-space process crashes, the timeout will revert to a deactive driver state.
It seems, though, that there's a lack of nice IOLock type classes for semaphores and mach messages. Or have I missed something?
Cheers, Matt
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
|