SDL-News: Save Save

Subject: SDL-News: Save Save
From: Sanders Richard (
Date: Fri Dec 19 2003 - 10:25:52 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From Sanders Richard <> to sdlnews -----

Mr Skelton: Comments and questions below

> -----From "William H. Skelton"
> <> to sdlnews -----
> Dear Susanne,
> ...
> >1. first a bad one: if there are two signals a process waiting for,
> >which
> >may arrive in any order. One sees then often specifications
> which, in
> >order to avoid the explicit interleavings use SAVE in order
> to force the
> >consumption in a particular order.
> >Duplication of programm text is not desirable, but here
> paralleising the
> >independent activities would be the nicer solution.
> How could this parallelizing be done?

Susanne calls this a bad reason; I think many will disagree with her, since
postponing a signal till the next state greatly simplifies the treatment of
conflicting initiatives (signal reception from independent sources).
Parallelizing means you must repeat the logic for all possible orders of
reception, resulting in more states, more transitions, more maintenance
problems (making sure that errors are corrected uniformly). But there is a
balance, hence SDL design rules.

> > ...the simplest solution is to maintain the signal
> in the signal queue.
> OK, we have been discussing this under the heading of 'packet
> buffering'
> with these notes:
> -- SDL and save doesn't allow an atomic flushing of the saved signals.

If by flushing you mean that they are discarded, this is possible. If the
process performs a transition to a new state, the save queue is (according
to SDL semantics) emptied into the input queue - and if the new state
explicitly "flushes signals" (i.e. a signal reception with an empty
transition) OR explicitly flushes signals (not mentioned in the input list),
then your "atomic flushing" is probably achieved.

> -- It means one state may depend on side-effects from another state, the
hot-potato problem.

It is not states that have side effects, it is the rearranging of the
received signals that has side effects. Note that the need for save is due
to the implicit consumption of signals that I mentioned above
("non-persistent message reception"). Compare to the programming language
CHILL, this is different: in CHILL signals are implicitly saved until
explicitly mentioned in a state input list.

> -- An explicit queue is closer to traditional software
> methods and closer
> to the application, which is best able to manage it.

What you mean by this is not clear. The save queue is an explicit queue in
SDL. If you are talking about several input queues with different priorities
then Yes, that is a way of reordering, but it adds other problems and
complications which all together do not make life easier.

> -- It is not clear maintaining the signal in the input queue is the
> 'simplest' solution.

Well, I suppose the definition of "simplest" is a matter of point of view:
that of designer, that of implementor, that of analyst, that of tool
provider. We who have worked with this for decades know that there are
balances and pros and cons, and we know that SAVE is used a lot, and, as Ms
Floch said, is quite well understood by users. Introducing something else
that does away with the save construct by acheiving it in a new way will
only cause confusion.

So frankly I suggest that SAVE be saved.


Richard Sanders
--End text from Sanders Richard <> to sdlnews ---
For extra SDL Forum Society benefits join at <>

This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT