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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.