Subject: RE: [SDLTF-Members] SDL-News: SAVE: Request for additional feedba ck
From: Frend Patrick-BPF005 (BPF005#motorola.com)
Date: Thu Jan 08 2004 - 17:43:49 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 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> --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>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT