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

[Stuart, question for you embedded below].

Philip,

About the points you raise:

1) It is an important feature of kill/reset/throw_it that the effect is immediate and asynchronous. These constructs are designed to be "powerful" constructs for urgent/exceptional sitns. where the perpetrator needs to know once the construct returns, that the job has been done. At least that was the original intent. It might be possible to design it alternately whereby the victim is only scheduled to execute in the same evaluate phase, but I'm not convinced about the motivation. You mention concerns about future multi-threaded implementations - can you elaborate? About the additional context switch, I'm not convinced it matters because I don't expect these constructs to be used all the time in a design - at least thats true for kill() and throw_it(); reset() I'm not sure, maybe used more commonly.

The contrast in semantics with sc_stop()/sc_pause() is intentional.

You have a valid point about a target possibly being in some "critical" state when a kill()/... is issued on it. To reconcile such cases, one way could be to allow the target to veto a kill/reset/throw_it issued on it - e.g. add a process API that a target can set up before entering any critical state; this API is checked by kernel before actually executing a kill/reset/throw_it call; if process is in critical state a failure status is returned to the perpetrator. Possibly enhance this a bit further to let the process signal (via an event) when it gets out of the critical state, such that the perpetrator on failure of the kill()/..., if it so desires, can wait for the process to get out of the critical state, and then issue the kill()/.... again.

We could possibly have more elaborate schemes - along the lines of how ovm_stop_request() can be vetoed in OVM. e.g., let the target provide a special member method that can "finish off" any critical state, this method can issue wait(); the kernel spawns off this special member method if the target is in critical state and kill() has been issued; the kernel "holds" the kill() until the special member method returns.

There are different possibilities here with varying degrees of implementation complexity, and varying degrees of modeling complexity either in target or in perpetrator. I'm in favor of keeping things as simple as we can get away with. The simple API whereby a target can indicate it is in critical state (possibly with the event-based API also to signal that it is out of critical state) seems adequate to me.

Thoughts? First, is this use model even worth accommodating in the spec? Stuart, John?

About 2), I think it is fine if kernel obligation on exceptions escaping from throw_it() is reworded the way you suggest.

Thanks,
-Bishnupriya

-----Original Message-----
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Philipp A. Hartmann
Sent: Thursday, August 12, 2010 4:24 AM
To: SystemC P1666 Technical
Subject: 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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.