Subject: Re: SDL-News: Output semantics, "several possible paths"
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Mon Jun 02 2003 - 22:45:34 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
Cris Fuhrman at christopher.fuhrman#etsmtl.ca wrote on 30/05/2003 20:46:
> It seems that SDL semantics are such that at the moment a signal is output,
> the destination process (even among many possible ones within the remote
> block) must be known (or will be decided nondeterministically if ambiguous).
> Again, Laurent Doldi's book, SDL Illustrated, provides clarification on this
> in Figure 94, the summary of output behavior. I must admit, however, that
> this is deceiving to me: a channel is intended to model delays in messages
> between blocks. Why can't the destination process be decided within the
> destination block (where the signal routes are multiplexed on the channel)
> rather than within the sending process? A block is an abstraction, and thus
> it would be useful indicate it as the abstract receiver of a signal. There
> seems to be no way to do this in SDL.
>
> This leads me to the following question. How does the FIFO queue of the
> channel (C1) relate to the FIFO queues of each process (P1B1 and P2B2)?
> Laurent Doldi's book implies that a channel has its own FIFO queue to delay
> messages and that processes have them as well.
>
> I realize I can avoid the ambiguity by clarifying which processes receive
> which signals inside B2, (i.e., not overlapping the signals on the
> multiplexed signal routes). There are cases when this is not possible. I ran
> into this trouble when I was trying to make abstractions about signals using
> CHOICE (see my last question about error modeling).
Dear Chris,
The reason that the decision which process can receive a signal is not made
when it is received at a block boundary is because this requires the
connection at the block boundary to have some behaviour (that is - deciding
how to route the signal). If you really want such behaviour a agent (in
SDL-92 or Telelogic Tau a process) has to be introduced to receive the
signal and then route it.
A channel does not really have a "FIFO queue", but is a pipeline in which
there can be no overtaking. On a shared memory implementation of the whole
system (usually the case for a monoprocessor or tightly coupled
multiprocessor systems), there are in reality no channels. Instead an output
"directly" (OK - maybe via the underlying system - depending on
implementation) writes the signal into queue in the input port of the
receiving process. Actually in some system there is only one signal queue
for the whole system and each signal in the queue is tagged with the
receiver identity.
Channels have more reality in loosely coupled distributed systems where it
really does take some time between sending and receiving the signal: that
is, when there is a transmission delay. For simulation this would be
modelled as a FIFO queue.
It seems to me that either you have to put router behaviour in somewhere -
either in the sending or the receiving block.
However, if your system is deadlocking because the selected receiver is not
ready for the sent signal there is probably a protocol error in any case.
Even if the process was ready to receive the signal when it was sent, if
there is some transmission delay it may be in a different state when it was
received. Alternatively, even if routing is done in the receiving block, the
protocol has to be such that the router can be certain which process
instances are likely to be free. Maybe what you really need is to store the
signals in a process in the receiving block which is then polled by end
receivers when they are actually ready to process the input.
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 15394 88462 Mob.:+44 7970 50 96 50--End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:49 GMT