SDL-News: Save & Buffering

Subject: SDL-News: Save & Buffering
From: William H. Skelton (
Date: Mon Nov 24 2003 - 14:10:50 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From "William H. Skelton" <> to sdlnews -----

Dear Susanne,

Thank you for your comments on the 'save' construct. Are your remarks
based on the communication with Keith or on the draft document from the SDL
Task Force, which may clarify the point even more?

Just for reference, why do you state "When processes have a single fifo
input queue, the save construct is indeed mandatory (and it's not
complicated to understand after all)."?

Perhaps the subject is not clear, we are not discussing buffering, but
instead the ability to control the buffering using the save construct. It
is this, the control of buffering, which is not part of the task force
subset. The execution model assumes signals will be buffered, otherwise,
as you say, blocking can occur...

Actually in the communication with Keith Moss we were discussing that the
decision not to include 'save' in the subset was based on a different
reason; it is possible to implement useful SDL systems without using the
'save' construct, and that was a fairly convincing reason for me...

Alles klar?


At 16:55 23.11.2003 +0100, Susanne Graf wrote:
>-----From Susanne Graf <> to sdlnews -----
>Dear William,
>I have a question/remark concerning your remarks on queues in SDL
>William H. Skelton wrote:
>>>Date: Fri, 21 Nov 2003 14:28:24 +0100
>>>From: "William H. Skelton" <>
>>>Subject: [SDLTF-Members] SDL Task Force Reply to Keith Moss
>>>Dear Keith,
>>> ...
>>>>I also feel that the "Save" construct is much easier to understand than
>>>>of ideas to be incorporated. I don't buy the idea that it complicates
>>>>If a queue has to be designed to cover the loss of the "save"
>>>>construct, the
>>>>queue will have to managed.
>>>The point is explained actually in some detail; the use of a queue is an
>>>application related issue, not a system issue. If you want a queue,
>>>declare it and use it with add/remove functions where and when you need
>>>it. Utilising an implicit system feature of buffering on a gate,
>>>because 'the mechanism is probably there anyway', hides the application
>>>related functionality and makes a system less readable.
>>>Some people have said it makes a system more readable, even though the
>>>principle is actually deeper than that. To make a decision on this, we
>>>concluded it is not needed for implementing the 'simplest, useful' SDL
>>>systems, and it was removed.
>what do you means by eliminating the queue concept? In SDL the fact that
>each object has a signal queue is absolutely fundamental, as it allows to
>make message sending non blocking.
>What would it mean that "there is no queue"?
> 1) if the receiver is not ready when the message arrives, it is lost ?
> 2) the sender is blocked as long as the receiver is not ready ?
> 3) or do you simply mean that the signals are not stored in a queue but
> simply in a bag and it's up to the receiver to consume the signals in the
> right order?
>1) and 2) seem not serious alternatives. 3) is an option, which makes the
>save construct useless (and almost forbids implicit discarding of non
>consumable messages). But it has also its drawbacks:
> - with a message bag, there exists no implicit order anymore and the
> designer MUST ALWAYS specify it explicitly even at an abstract level
> (not specifying an order at all, that is leaving it non deterministic, is
> very likely to lead to non wanted behaviours, as certain signals need in
> general to be consumed in order of arrival)
> - there are some nice theories for systems with fifo communication
> making validation possible (and the save construct is in general not
> harmful). In the case of prioritised message consumption, no such
> theoretical support exists.
>When processes have a single fifo input queue, the save construct is
>indeed mandatory (and it's not complicated to understand after all). An
>elegant way to avoid it, and more generally, to distinguished which
>signals are ordered and which are unordered or have to be managed, is to
>allow more than one input queue. this is not "chaos" like when using a
>"bag", but it is still abstract, as it leaves a lot of room to decide how
>to order the signals of different queues.
>Susanne Graf
>Susanne Graf | tel : (+33) (0)4 56 52 03 52
>VERIMAG | fax : (+33) (0)4 56 52 03 44
>2, avenue de Vignate |
>F - 38610 Gieres | e-mail:
>--End text from Susanne Graf <> to sdlnews ---
>For extra SDL Forum Society benefits join at
>For help, email "" with the body of your email as:
> help
>or (iff this does not answer your question) email:

William H. Skelton, Engineering Dept.
SOLINET GmbH Solutions for Innovative Networks
Mittlerer Pfad 26, 70499 Stuttgart, Germany
Tel +49 711 1398 1377, Fax +49 711 866 1240
Mobile +49 171 247 6688,

--End text from "William H. Skelton" <> 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