Process Control Extensions - kill/reset/throw scheduling, exception handling

All,

I have some questions regarding the current specification of killing,
asynchronously resetting and throwing exceptions in processes as
specified by the proposed Process Control Extensions.

kill()/reset()/throw_it() scheduling:
-------------------------------------

Quote:
  "kill() has an immediate/asynchronous effect. For a target thread,
  the target thread shall immediately exit its function, and return
  control to the initiator process. No other processes shall execute
  between the time the kill() of a target process is ordered and the
  target obliges."
Similar for reset() and throw_it().

Is there actually a strong rationale for this strict requirement?
Why wouldn't it be enough to require an effect in the current (or
immediately following) evaluation cycle?

IMHO, this requirement has some drawbacks for compliant implementations:

 - It effectively prohibits future, multi-threaded implementations
   of SystemC, since it cannot be foreseen, when processes issue
   kills etc.
 - At least one additional context switch is required for each kill,
   which is quite costly.
 - It feels inconsistent with sc_stop (and sc_pause, eventually), which
   is currently defined to be effective after the suspension of the
   current process.

  As a side note: Lifting this to the current evaluation phase may even
allow the use of wait() etc. during unwinding, which may be useful in
the throw_it case (e.g. to finish already started transactions). Do we
need to define the behaviour e.g. for the TLM2 convenience sockets, when
an initiator is killed in the middle of a transaction?

Exception handling:
-------------------

In case of uncaught exceptions, thrown within a process (whether by
throw_it(), or otherwise), the Process Control Extensions proposal
requires, that an implementation shall catch them and report them as
"UNKNOWN EXCEPTION".

  As of now, IEEE 1666 does not say anything about implementation
requirements regarding exceptions escaping from an application. Do we
need to fix this? Or shall we leave this as being implementation
defined or unspecified? Maybe it is enough to require, that "it shall
be an error, if the throwee thread does not catch the exception".

Thanks,
  Philipp

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
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.