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

From the points that Philip raised, I had considered whether there is need to provide a veto mechanism to the target via a simple API whereby the target can say no to any kiil/reset/throw_it request when it is in a "critical" state.

In internal discussions with Stuart and Mac, we concluded that the existing mechanism whereby the target has the provision of catching sc_unwind_exception (previously called sc_kill_exception) and performing any necessary clean-up, is adequate to address the requriement of the target being able to leave things in a clean state.

So the proposal is back to as it stands.

Thanks,
-Bishnupriya

-----Original Message-----
From: Stuart Swan
Sent: Thursday, August 19, 2010 5:12 AM
To: Bishnupriya Bhattacharya; Philipp A. Hartmann; SystemC P1666 Technical
Subject: 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.