Re: SDL-News: Fwd: [SDLTF-Members] SDL Task Force Reply to Keith Moss


Subject: Re: SDL-News: Fwd: [SDLTF-Members] SDL Task Force Reply to Keith Moss
From: Susanne Graf (Susanne.Graf#imag.fr)
Date: Sun Nov 23 2003 - 15:55:35 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 Susanne Graf <Susanne.Graf#imag.fr> 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
>> To: sdlnews#sdl-forum.org
>> From: "William H. Skelton" <W.Skelton#SOLINET.com>
>> Subject: [SDLTF-Members] SDL Task Force Reply to Keith Moss
>> Cc: members#sdl-task-force.org
>>
>> Dear Keith,
>>
>> ...
>>>
>>> I also feel that the "Save" construct is much easier to understand
>>> than many
>>> of ideas to be incorporated. I don't buy the idea that it complicates
>>> matters.
>>> 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  | http://www-verimag.imag.fr/~graf/
F - 38610 Gieres      | e-mail: Susanne.Graf#imag.fr
------------------------------------------------------------------------

--End text from Susanne Graf <Susanne.Graf#imag.fr> 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