RE: Channels versus Methods

["Gerald Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>]

Peter,

This is good work!

Although your call channel does not support remote channels it is fast and
easy. My call channel easily supports remote channels but it is not as fast
and less easy than yours is. Hmm, in CTJ a call channel does not have to be
a remote call channel, because the primitive low-level channels are already
remote channels. The technique I used should perhaps be brought outside the
call channel. The idea of creating remote call channels can be solved in
other ways based on the techniques in my call channel approach and using
your call channel.

For example, say we have two processes A and B running in parallel. Process
A is the client and process B is the server. Process A calls methods from
process B via a call channel c.


+-----+     +-----+
|  A  |---->|  B  |
+-----+  c  +-----+

Figure 1.

With my call channel you can easily create a remote call channel. By adding
link drivers to the call channel, figure 1 can easily be changed into figure
2. (c = Gerald's call channel using link drivers for the link).

+-----+     |     +-----+
|  A  |---->|---->|  B  |
+-----+  c  |  c' +-----+
System 1         System 2

Figure 2.

The penalty of the overhead with my call channel approach is for internal
call channels too expensive (figure 1).


In combination with your call channel and the techniques used in my call
channel we can establish external communication by adding a sender and a
receiver process. The sender and receiver can use the techniques of my call
channel implementation. See figure 3. (c = Peter's call channel)

+-----+     +------------+    |    +--------------+     +-----+
|  A  |---->| CallServer |<==>|<==>| AcceptServer |---->|  B  |
+-----+  c  +------------+    |    +--------------+  c' +-----+
System 1              toServer/fromServer              System 2

Figure 3.

Process A invokes a method on c and process CallServer (sender) accepts the
call from c (i.e. CallServer invokes accept() method on c). Then the
corresponding method of the CallServer process (that is called by c on
CallServer) sends the arguments and receives the result via the toServer and
fromServer channels. The toServer and fromServer channels are remote
channels. The CallServer has the same interface as process B. The
AcceptServer process receives the arguments from the toServer channel,
invokes the corresponding method on c' and returns the result via the
fromServer channel. Process B accepts the calls from AcceptServer by
invoking accept() method on c'.

The CallServer and AcceptServer processes use almost the same techniques as
those in ButtonCallChannel.

Note: In CTJ the Processes A, B, CallServer and AcceptServer are hardware
independent. The link drivers for the external link are plugged in the
toServer and fromServer channels.

I've not tried this example yet, but it should work. Fortunately, my
criteria about call channels still hold. Peter, I may *inherit* your call
channel idea for CTJ. :-)

In CTJ the implementation of the accept() and sync() methods can be hidden
by introducing an abstract CallChannel class that implement these methods.
The class diagram for the ButtonCallChannel would be

+----------------+      +--------------------+      +-----------------+
|csp.lang.Channel|<|----|csp.lang.CallChannel|<|----|ButtonCallChannel|
+----------------+      +--------------------+      +-----------------+

Figure 4.

ButtonCallChannel inherits CallChannel and CallChannel inherits Channel.
This would automatically make the ButtonCallChannel ready for alting on an
ALT. Here, inheritance works. :-()

Problem with call channels
==========================
When the caller A invokes a method on callee B (via a call channel) and this
method performs a call back to A (via a call channel) then the program will
deadlock because process A is calling the method on B and does not accept
calls from B.

Is there a way to overcome this problem?

Note: This is the same problem that occurs with nested synchronized callback
functions in Java where methods are synchronized on different objects. This
will deadlock. Nested synchronized callback functions that are synchronized
on the same object will not deadlock.

Gerald.