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

Philip, All-

I'll briefly comment on some of your points below.

- I do not believe that the performance concern that you mention concerning
context switches when kill etc is used is important, since these constructs
are likely to be rarely used in the overall simulation.

- I believe that having kill/reset/throw have the immediate semantics as
in the Cadence proposal is appropriate since it is provides the "least surprising"
results to the user (e.g. by the time the kill/reset/throw_it call returns to the
perpetrator process the victim is dead, etc.) Keep in mind that these features such
as kill and throw_it might be used to model abstract SW schedulers in SystemC - to do
so the delayed effect that Philip proposes would seem to be the wrong approach.

- I am opposed to adding additional capabilities (e.g. along the lines of Bishnpriya's
ovm_stop_request machinery etc) without a compelling reason.

Thanks
-Stuart

>-----Original Message-----
>From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf
>Of Bishnupriya Bhattacharya
>Sent: Tuesday, August 17, 2010 12:02 AM
>To: Philipp A. Hartmann; SystemC P1666 Technical
>Subject: 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.
>

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