Subject: Fwd: RE: SDL-News: SAVE: Request for additional feedback
From: William H. Skelton (W.Skelton#SOLINET.com)
Date: Fri Jan 09 2004 - 09:20:20 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 "William H. Skelton" <W.Skelton#SOLINET.com> to sdlnews -----
Dear Frend (first name I guess?),
Thanks for your email.
Your comments are interesting and the semantics do correspond to the point
Alkis has raised on the SDL Task Force mail exploder. But it seems to me
that there is no way in SDL to achieve this at the moment.
Just for clarification Rick and others have pointed out there isn't a queue
to flush anyway, the signals are held in the same input queue as others and
simply become available when a new state is entered
Although I think this as a matter of interest is semantically the same as a
save queue, it shows why the flushing is not atomic, i.e. the suggested
alternative mechanism is to discard the signals to be flushed in the new state.
Clearly this would also flush any new arrivals and this is problem still to
be solved. Therefore the SDL Task Force has already concluded, pending new
information, that the preferred way to handle applications leading to this
problem (buffering application data for sending later) is to use an
application queue.
This can implemented using SEQUENCE OF, which is valid SDL, and a few
operators, which are still being discussed, but seem to be available in
SDL-2000 in one form or another.
In this case save is not needed at all, but there are other cases we are
still considering where it may be.
Just for reference, do you have any real applications at Motorola using
save? Are you able to shed any light on the real need for this language
construct?
This discussion is continuing on a mail exploder run by the task force;
anyone can register at the home page (www.SDL-Task-Force.org).
William
>X-Authentication-Warning: sdl-forum.org: sdlforum set sender to
>owner-sdlnews#sdl-forum.org using -f
>From: Frend Patrick-BPF005 <BPF005#motorola.com>
>To: sdlnews#sdl-forum.org
>Subject: RE: [sdl-forum] [SDLTF-Members] SDL-news: SAVE: Request for
>additional feedba
> ck
>Date: Thu, 8 Jan 2004 17:43:49 -0000
>X-Mailer: Internet Mail Service (5.5.2657.2)
>X-Sender: owner-sdlnews#sdl-forum.org
>X-IMAIL-SPAM-DNSBL: (fiveten,10224688,127.0.0.7)
>Sender: sdl-forum-owner#weyler.com
>Reply-To: sdl-forum#weyler.com
>
>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 Frend Patrick-BPF005 <BPF005#motorola.com> to sdlnews -----
>
>I'm not a member of the task/force but this is in the general news group
>as well,
>so I have just replied there.
>
>When P1 gets scheduled it has the following messages on input queue:
>
>1: E1 <saved>
>2: E2
>3: E1
>4: E3
>...
>
>E2 wants to cause the input queue to be "reset", removing the first E1
>but not removing the second E1. The target state of the transition due to
>E2 does not want to have to identify/process any signals that occurred
>before the reset but needs the ones that come after it (even if they are
>already in the queue because of a delay in scheduling the process)
>
>There is a race condition where-by the second E1 may be queued before or
>after the task is scheduled depending on the implementation and timing.
>Making the reset only reset down to where the signal that provoked the
>reset would illuminate the race condition and make things more deterministic.
>
>It would be sensible semantics that the queue was flushed up to the signal
>that
>instigated the reset (E2). It's also very simple, easy to implement/understand
>and it doesn't preclude the inclusion of "save" or "priority input" etc.
>
>This would work whether E2 was processed because E1 was saved OR because
>of a priority input or signal priority, or any other means of out of order
>signal processing.
>
>Just my 2p worth.
>
>
>-----Original Message-----
>From: owner-sdlnews#sdl-forum.org [mailto:owner-sdlnews#sdl-forum.org]On
>Behalf Of Susanne Graf
>Sent: 08 January 2004 16:11
>To: members#sdl-task-force.org
>Cc: sdlnews#sdl-forum.org
>Subject: Re: [SDLTF-Members] SDL-news: SAVE: Request for additional
>feedback
>
>
>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 -----
>
>Indeed, discarding signals which have to be considered as "old" is
>difficult in
>SDL, and this has nothing to do with the save construct. What would be
>needed is
>not to eliminate the SAVE construct, but to add the possibility to discard
>signals satisfying some "old" criterion, and this should not only depend
>on the
>signal typ, but on its parameters (which might contain a sequence number,
>a time
>stamp, ...).
>Obviously, this doesn't make things simpler but more complicated. But you are
>right, the identified problem is a real problem.
>
>Susanne
>
>Rick Reed TSE wrote:
> > William H. Skelton at W.Skelton#SOLINET.com wrote on 01/08/04 13:04:
> >
> >
> >>A problem has been identified that there is no atomic way to flush signals
> >>that have been saved. For example, if a signal E1 is saved, then E2
> arrives
> >>causes a reset of the state machine, then another E1 arrives, there is
> no way
> >>to flush at the time of the reset the saved E1 without losing the new E1.
> >
> >
> > Even without SAVE it is not clear how this can be achieved. If we assume
> > that the each E1 is buffered internally, when E2 is received the buffer
> > could be cleared as part of the reset. If when E2 is received there was an
> > E1 in the input queue, this would have arrived BEFORE the reset, but would
> > NOT be in the internal buffer and would NOT be cleared. Discarding the E1
> > after the reset would also mean that any E1 signals arriving after the
> reset
> > would also be discarded.
> >
> > --
> > Rick Reed - rickreed#tseng.co.uk
> > Tel:+44 15394 88462 Mob.:+44 7970 50 96 50
> >
>
>
>--
>------------------------------------------------------------------------
>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>
>For help, email "majordomo#sdl-forum.org" with the body of your email as:
> help
>or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org
>--End text from Frend Patrick-BPF005 <BPF005#motorola.com> to sdlnews ---
>For extra SDL Forum Society benefits join at
><http://www.sdl-forum.org/Society/members.htm>
>For help, email "majordomo#sdl-forum.org" with the body of your email as:
> help
>or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org
------------------------------------------------------------------------
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
W.Skelton#SOLINET.com, www.SOLINET.com
--End text from "William H. Skelton" <W.Skelton#SOLINET.com> 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