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