Propagation / Deception
"Neal H. Walfield" <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.l4ka.general |
|---|---|
| Message-ID | <87fxs7ewev.wl%[email protected]> |
I have a server with a service thread and a worker thread. The service thread receives and normally responds to RPCs. However, a client can request to be informed when an event occurs. If the event has already occurred, then the service thread responds itself. Otherwise, the requested is queued on the object and when the event occurs, the worker thread responds. As the client thread is in a closed wait on the service thread, the worker thread uses propagation so as to be able to respond directly. +--------------------------+ +-----------+ | | | \ | | \ service \ <+-----+- / client | | / worker / | | \ | | \ \ | +-----------+ | | +--------------------------+ This normally works fine. However, I have encountered a problematic scenario. This arises as the service and worker thread use a lock to synchronize access to the shared objects and the lock works as follows: if the lock is held, enter a closed wait on the lock's owner. Now, consider the scenario where the worker thread takes the lock and the service thread, while responding to an RPC from a second client, then also tries to take the lock. In this case, the service thread enters a closed wait on the worker thread. Now, while the worker thread has the lock, an event occurs and it sends some delayed reply. Because it uses propagation and the service thread is in a closed wait on the worker thread, the service thread is changed to wait for a message from the second client!!! This is not the behavior that I desire. A solution to this problem is to propagate the request from the service thread to the worker thread. However, the only purpose of this IPC is to update the thread the original client is waiting on. Although annoying, it is not really tenable as the worker does not listen for RPCs and would thus require some extra coordination. What I am considering instead is to have the worker send an RPC to the service thread and then have the service thread reply directly. This is also annoying, but slightly less so: the worker can only send the RPC when it does not have a lock, and it might block for a short while. What I'd like is for the ability to disable this update of the originator's from field. That may require making deceiving IPC first class but I think there are three bits still available in the message tag. Perhaps what I want is already possible. Or, perhaps there is a better way to achieve what I'd like. Any feedback is appreciated. Neal