Deadlock in rpc interprocess communication

Thomas Oeser DI AP 313 thomas%apgraph%ap542 at ztivax.siemens.com
Wed Aug 22 20:58:54 AEST 1990


Hy RPC Specialists!

Can anyone help me to solve the folowing deadlock situation I have:

		             1 calls 2
                     +-----------------------+
		     |                       |
                     |                      \ /
		+----+----+		+----+----+
		|         |		|         |
    Start ----->| Process |		| Process |
		|    1    |		|    2    |
		|         |		|         |
		+---------+		+---------+
		    / \                      |
                     |                       |
                     +-----------------------+
			     2 calls 1

I have a set of interworking processes communicating via RPCs. They implement a
distributed object oriented environment, where the methods of a particular
object are implemented in several processes (e.g. Mailing, Editing, Storing,
etc.). In addition (most of these) are driven by a user interface (i.e. are
interactive and may act as the initator of an action).

In this scenario the following situation may happen:

	- Process 1 calls Process 2 and this call returns;
	- initiated by this call Process 2 continues processing and calls 
	  Process 1 and waits for a return;
	- Now, if another cycle of this type is started (i.e. call of 2 by 1)
	  when process 2 is just calling process 1, both processes hang in
	  the call_rpc() procedure waiting for the reply of the other process.

The point is that within this scenario I have no longer processes which are
pure clients or servers. Both aspects are found in in all processes, since
they are calling each other.

	NOTE - The multiplexing of the channels is done (of cause) using
	select() and poll(), respectively.

The best solution of this problem would be, if the sending part of call_rpc()
could be separated from the recieving part. I.e. a function

	call_rpc_nowait( ......, returnHandler )

could be constructed that returns immediately after the sending of the rpc is
done and the return handler is called after a select indicates that data (i.e.
the reply) is to be expected on the corresponding channel.

A fork of the calling process for processing the rpc is not possible since I
have already a couple of processes interworking and I don't want to stress 
this resource too much (BTW, I believe this should not be done anyway except
you hace threads :-) ).

Most likely would be to solve the problem with standard functions from the rpc
toolkit, since I have to handle 3 different Unix operatinmg systems (SINIX --
System 3.2 based --, SCO and Unix System V Release 4.0).


Thanks in advance

	Thomas Oeser


*********** DISCLAIMER: All opinions stated here are strictly my own ***********
--------------------------------------------------------------------------------
Internet:	thomas%apgraph%ap542 at ztivax.siemens.com
Europe:		thomas%apgraph%ap542 at ztivax.UUCP
UUCP:		...!uunet!mcsun!unido!ztivax!ap542!apgraph!thomas
Phone:		+ 49 89 636 47537
Fax:		+ 49 89 636 45522
Postal Mail:	Siemens AG, DI AP 313, Carl-Wery-Str. 22, D-8000 Munich 83
		West Germany
--------------------------------------------------------------------------------



More information about the Comp.unix.wizards mailing list