Re: Empty events lists

From: Philipp A. Hartmann <philipp.hartmann@offis.de>
Date: Tue Nov 02 2010 - 03:40:05 PDT

Puneet,

I can understand your interpretation. But as you can see from Dave's
question, there are other possible and equally valid interpretations of
the semantics of empty lists.

  The semantics you describe can easily be implemented in user-designed
classes, that build around event lists (hooray, it's possible now!).
They can call the appropriate wait() or even no wait at all, depending
on the corner case and the application requirements, e.g.:

class join_point
{
  sc_event_and_list list;
public:
  void add( sc_process_handle & h )
    { list &= h.terminated_event(); }

  void wait()
    { if( list.size() ) wait( list ) else /* do nothing */ ; }
};

So I would still favour to follow Bishnupriya's proposal:

 - error out on wait( empty_list )
 - warn on wait( timeout, empty_list );

Greetings from Oldenburg,
  Philipp

On 02/11/10 11:29, Puneet Goel wrote:
> I think my point needs some elaboration.
>
>> If we think semantically, an empty sc_event_and_list should be equivalent to
>> waiting for an event that triggers immediately -- more like
>> wait(SC_ZERO_TIME).
>
> Say we are programming at a meta-level, by creating a script (in
> python, or using template meta-programming) and we have a situation
> where a variable number of events are gating some process (in a
> logically anded fashion). Now think of a situation where such a gating
> event list is empty. Now that there are no gating events, we should
> execute the process immediately.
>
>> And an sc_event_or_list should be equivalent to waiting
>> for an event that never happens -- practically closer to wait(SC_MAX_TIME).
>
> This would be a situation where a variable number of events are
> enabling a given process. This corner case would be where no enabling
> event is present and the process therefor does not get a chance to
> execute. So we keep waiting.
>
>> But does this make sense? Maybe in some situations where the SystemC code is
>> outputted by a code generator?
>
>> Regards
>> - Puneet
>> --
>> CoVerify Systems Technology
>

-- 
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 Tue Nov 2 03:40:30 2010

This archive was generated by hypermail 2.1.8 : Tue Nov 02 2010 - 03:40:33 PDT