Subject: RE: SDL-News: Output semantics, "several possible paths"
From: Cris Fuhrman (christopher.fuhrman#etsmtl.ca)
Date: Tue Jun 03 2003 - 00:29:33 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 "Cris Fuhrman" <christopher.fuhrman#etsmtl.ca> to sdlnews -----
> From: owner-sdlnews#sdl-forum.org [mailto:owner-sdlnews#sdl-forum.org]On
> Behalf Of Rick Reed TSE
Hi Rick,
> [...]
> 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.
Thanks -- I had thought of this solution as well, but was hoping not to have
to implement it by hand ;)
> 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.
In fact, my system was deadlocking because there were "several possible
paths" (the warning from Tau) since several processes on the receiving end
of the channel were capable of receiving the signals. However, the behavior
I wished to model was something like the first process receives the first
signal, the second receives all subsequent signals (much like how a server
receives an initial request and then spawns a daemon process to hand the
subsequent ones). I didn't want to model this with multiple channels, as
this gets more complex. In fact, the deadlock arises when the system ALWAYS
chooses the first process to receive all the signals.
Let's call it a case of me assuming SDL was more like PROMELA in the sense
that channels could be shared by processes, and that a process waiting for a
message may make a transition if that message is available in the "shared"
queue. Since SDL signals are always addressed to a particular process at the
moment of OUTPUT, this is clearly very different. Thank you for clearing it
up.
> 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.
Thanks again for the suggestions. They are helpful. I also think that using
signals in SDL corresponding to the OSI service primitives (request,
indication, response, confirmation) plus the actual protocol messages (which
actually travel over the network as PDUs) much of this is feasible I think.
However, it adds more bit states to the model, complicating the validation.
I may have forgotten to mention that validation is one of my primary goals
for using SDL.
---- Prof. Christopher Fuhrman Departement de genie electrique Ecole de technologie superieure--End text from "Cris Fuhrman" <christopher.fuhrman#etsmtl.ca> 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