Subject: Re: SDL-News: How are "Shared-memory" and "Message passing" expressed differently in SDL?
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Tue Mar 25 2003 - 15:35:06 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 -----
D Wang, Electrical & Electronic Engineering at Diyu.Wang#bristol.ac.uk
wrote on 17/03/2003 18:47:
> Dear friends,
>
> Are there different constructs in SDL to express (specify) the difference
> between "Shared-memory" and "Message passing" mechanisms?
>
> Thanks in advance.
>
> Best regards,
>
> diyu
Dear Diyu,
Although it is not entirely clear what you want to express, I'll try to give
answers.
The answer is slightly different depending on whether you are using SDL-2000
or not.
I'll give the answer for older SDL first - because unless you are using the
SITE tool, you will not be using SDL-2000.
SDL-92 (before SDL-2000)
++++++++++++++++++++++++
In SDL-92 each lowest level block is distribution independent and can
therefore be implemented on a separate processing unit without any common
memory. SDL only requires that blocks can communicate by signals ("message
passing"). However, a non-delaying channel between two blocks implies that
communication between the blocks (at least by this channel) is synchronous
(the signal is placed in the queue of the receiving process at the same time
as it is output from the sending process). A non-delaying channel therefore
implies the two blocks should be implemented within single processing unit.
Shared memory
-------------
There is no SDL mechanism for sharing memory between blocks.
To some extent SDL assumes that blocks are location independent and
therefore may be running on different processing systems, and all
communication between blocks has to be by message passing - either
explicitly or implicitly by using remote procedures or remote variables.
SDL assumes that each process instance can be interpreted (SDL terminology -
usually synonymous with "executed") at the same time as other process
instances, regardless of whether they are in the same or different blocks.
This implies that the SDL system COULD (but does not have to be) implemented
with a processor per process. Having multiple processors, does not exclude
the possibility that they could have shared memory, but in that case there
could be a danger that two processes are reading and writing the same data
at the same time, giving rise to inconsistent values.
Variables has no separate existence. Every variable is owned by a process
instance. If the variable is not within a procedure the variable is created
when the process is created. If the variable is in a procedure, it is
created when an instance of the procedure is created (that is - when the
procedure is called). A variable in a procedure is owned by the process
enclosing the procedure. Note that for a "remote procedure", the actual
procedure instance (and its variables) are created in the "remote" process.
There is no "shared memory" as such, but between two processes within one
block a variable declared as REVEALED by one process and VIEWED by other
processes in the same block (provided there is a view definition in the
process). If there is more than one instance of the revealing process, a
process identity (Pid) instance value has to be given in the view expression
to bind the expression to a particular variable. Variables in procedures
cannot be revealed.
A process can be subdivided into services, provided each service has a
disjoint set of signals. When the process is interpreted, which service is
interpreted at any given time depends on the next signal to be processed in
the input queue. There can be data declared at the process level that is
shared between the services.
Message passing
---------------
Data of a process can be declared to be EXPORTED in which case there can be
a "REMOTE VARIABLE definition" in any enclosing block (including the
system). This does not actually define a variable, but a pair of implicit
signals for communicating with the process that owns the variable. In a
process that defines an IMPORTED variable with the name of the remote
variable, an exchange of signals to obtain an exported value of the EXPORTED
variable can be invoked by an IMPORT expression. This expression causes the
importing process to wait in an implied state for the reply signal
containing the value.
The exporting process has control of the exported value. An EXPORT causes a
copy to be made of the value of the EXPORTED variable, which is used as the
exported value. When a query signal is received from an importer, it is the
exported value that is returned in the reply signal. Note that this may
differ from the value of the EXPORTED variable if this has been changed
since the EXPORT.
In an importing process, the value received in by an IMPORT is copied into
the IMPORTED variable, which is otherwise used just like any other variable.
Where there are multiple process instances that have EXPORTED variables
using the same remote variable, the IMPORT expression will need to be given
a process identity (Pid) instance value to determine the exporting process
instance.
The value in any variable can be exchanged between processes without using
the IMPORT/EXPORT mechanism, simply by passing the value in a signal or as a
value in the response to a remote procedure call.
SDL-2000
++++++++
Shared Memory
-------------
The REVEALED/VIEW mechanism is no longer available.
This is replaced (to some extent) by variables at the block (including the
system) agent level. These variables are declared in the normal way and if
the variable is visible it can be accessed. In theory there are access
procedures to read and write the variables that are part of the block agent
state machine, but from the user point of view these can (under most
circumstances) be treated as normal variables in shared memory. In most
cases no other behaviour will be specified for the block agent state
machine, and if the block is implemented by a single processor the "read and
write procedures" can be implemented as direct read and write of the memory
for the variables. So in general, an agent (system, block or process) can
define "shared variables" that are accessible to any contained agent (block
or process).
Unlike SDL-92 REVEALED/VIEW, any agent in which a variable is visible can
change (as well as read) the variable: there can be many writers. It is
therefore safer to define the variables as EXPORTED in the state machine of
an agent, in which case only the owning agent can write to the variable. The
EXPORT and IMPORT mechanism are similar to SDL-92, except that an IMPORTED
variable definition is neither required nor allowed in SDL-2000.
The SERVICE mechanism of SDL-92 is replaced by state aggregation. A process
can have variables that can be accessed by any of its aggregate states.
A process can contain processes in SDL-2000. The variables defined at the
process agent level are visible to and accessible by contained processes.
Variables defined within the state machine of a process are not visible to
other processes, but can be EXPORTED. Note that to protect variables from
enclosed processes, the process has to be defined using an explicit state
diagram containing the variable definitions referenced from the process
diagram.
All processes contained within a process are required to scheduled on a
mutual exclusion basis (that is - only one of the processes - including the
container process - can be in a transition at any one time). Therefore by
putting a process container with data around other processes it ensures that
this data can be safely shared ("shared memory").
Message passing
---------------
Message passing in SDL-2000 is the same as SDL-92, with the addition that
timeouts can be specified for IMPORT and remote procedures.
-- 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