Subject: Re: SDL-News: particular case of parallelism specification
From: rick reed (rickreed#tseng.co.uk)
Date: Sat Oct 11 2003 - 09:17:13 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 <rickreed#tseng.co.uk> to sdlnews -----
on 10/10/03 18:00, Andreia at andreia#det.ua.pt wrote:
> I am starting in SDL by specifying a control unit
> behaviour.
> I have two FSMs. One calls the other when a specified
> state is reached. The problem is that after this state
> I need the two FSMs running in parallel, i.e. the caller
> FSM proceeds with its execution and the called FSM starts
> to run.
> How is it possible to specify this situation graphically
> in SDL?
Dear Andreia,
This is a "master"/"slave" scenario.
There are at least three ways of doing this.
In all cases each FSM should be specified as a process. This means that they
are scheduled separately and (as far as SDL is concerned) can run in
parallel and potentially can run on different processors. Whether they
actually run in parallel or or different processors depends on the actual
run time system and is not defined by SDL.
Note: by default all processes are FSM that run in parallel in SDL (except
for (sub) processes nested inside processes in SDL-2000). Of course, if the
is no signal ready to be input for a process it remains dormant in a state
waiting for a valid signal to arrive. Any further constraint on actually
processing signals in an active process (one with signals ready to input) is
imposed by the run time scheduling system. For example, on a mono-processor
processes can not really run in parallel, so the run time system has to
schedule the processor time for pseudo-parallelism
1. Method 1 - by a signal
Each process is defined to have one initial instance and a maximum number of
instances as one by specifying <number of instances> as (1,1). When the
system is initialised one instance of each process is created and start
transition of each process instance is interpreted.
The slave process can then wait in state (called - for example - "idle")
until it receives a specific signal from the master process.
When the master process reaches the point where the slave is to be activated
the signal is output to the slave process. Once this has been done both
processes will be active and ready to run in parallel (subject to the
constraints of the run time system). The signal used can (of course) have
parameters.
2. Method 2 - by a remote procedure call
This is essentially the same as method 1 except communication is by a remote
procedure call. The slave process waits for the procedure which is shown by
name in an input and should be followed by a transition leading to a new
state.
The slave is invoked by calling the remote procedure, which may have
parameters and a return.
The advantages of this method are:
a. The remote procedure call is a handshake, therefore it is known that the
slave process has received the procedure call and interpreted the procedure
before the next action is interpreted in the master process.
b. While the procedure body is interpreted (which could include internal
states - but make sure the master is not called as this creates a deadlock)
the master process is in a hidden state waiting for the return and therefore
is not active.
c. The procedure may return a value, which can include the process identity
of the slave (useful if there is more than one possible slave).
3. Method 3 - dynamic slave creation
The master process is defined to have one initial instance and a maximum
number of instances as one by specifying <number of instances> as (1,1).
When the system is initialised one instance of the master process is created
and start transition is interpreted.
The slave process is defined to have zero initial instances and a maximum
number of instances as one by specifying <number of instances> as (0,1).
When the system is initialised no instances of the slave process are
created. The slave process must be defined in the same block as the master
process (Note: SDL-2000 relaxes this restriction somewhat, but as far as I
am aware no tools support these newer features).
When the master process reaches the point where the slave is to be
activated, an instance of the slave process is created using a CREATE. Once
this has been done both processes will be active and ready to run in
parallel (subject to the constraints of the run time system). After the
CREATE the master process has the identity of the slave in OFFSPRING.
The create can have parameters to pass to the slave specified in the header
of the slave. The slave process is started at its start transition with the
actual parameter values from the create.
Synchronisation
===============
I assume that at some point the master and slave will need to be
synchronised again. This can done by a number of methods but the simplest is
for the master process to wait in a state for a signal from the slave that
it has completed it actions.
In the case of dynamic slave process creation, the slave would output a
signal to the master process then interpret a STOP, and the instance of the
slave would cease to exist.
Graphics
========
Nothing special is needed. However, if dynamic creation of the slave is used
a dotted arrow (a "create line" can be shown from the master to the slave).
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 15394 88462 Fax:+44 15394 88218 Mob:+44 7970 50 96 50--End text from rick reed <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:50 GMT