RE: terminated_event()

John,

yes, kill() notifies the terminated_event of the process, both for thread and method.

Re adding reset_event(): the semantics are - for asynchronous reset(), it triggers when proc_handle.reset() is issued, for synchronous reset, it kicks in when effective sensitivity of the process triggers and it is reset. The timing of the triggering happens during the resetting of the process, but the effect (e.g. if any proces is sensitive to reset_event()) is only visible after target process has run from beginning and yielded.

This is fine with with me and IMO is a good idea. One subtle side effect - if a process is reset() before sim start, the current semantics says there is no effect on the process. That might now need changing to say - the first time the process executes, it will be reset, but the only visible effect will be that the reset_event() gets notified.

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, September 17, 2010 5:06 PM
To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
Subject: terminated_event()

Bishnipriya, All,

sc_process_handle::kill does notify the terminated_event for the underlying process instance, right? In which case, should we consider adding a reset_event that is notified whenever reset() is called, explicitly or implicitly?

Thanks,

John A

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.