Re: Empty events lists

From: Philipp A. Hartmann <philipp.hartmann@offis.de>
Date: Mon Nov 01 2010 - 16:29:28 PDT

John,

On 01/11/10 23:26, john.aynsley@doulos.com wrote:
>
> We have not explicitly discussed the semantics of empty event lists, e.g.

I vaguely remember, that you (or someone else?) suggested forbidding
this corner case some time back.

> sc_event_or_list list;
> assert( list.size() == 0 );
> wait( list );
>
> I propose that "If the event list object is empty, the effect shall be
> the same as omitting the event list argument from the call."

Especially for the "list-only" wait() case, I don't really like this.
The user intended to dynamically wait on an (unfortunately empty) list,
why should the process suddenly be triggered by its static sensitivity?

Consider the following:

  SC_THREAD(...)
    sensitive << ev1;
  // ...
  sc_event_or_list list1, list2 = ev1 | ev2;

  // never triggered by ev2, but why?!
  wait( list1 );

I think, such a bug (list1 instead of list2) might be a pain to track
down, especially in more complex situations. So I would prefer to at
least require a warning in case of an empty list.

  For the timeout variants, ignoring empty lists might not be that much
of a problem, since at least the process is never triggered by an
"unrelated" event. For consistency reasons, we might want to issue a
warning as well, though.

Greetings from Oldenburg,
  Philipp

> In other words, in the example above,
>
> wait( list );
>
> shall be equivalent to
>
> wait();
>
> and
>
> wait(10, SC_NS, list);
>
> shall be equivalent to
>
> wait(10, SC_NS);
>
> Is that acceptable?
>
> John A
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Nov 1 16:29:49 2010

This archive was generated by hypermail 2.1.8 : Mon Nov 01 2010 - 16:29:50 PDT