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

Tor, All-

Again, I think the "immediate semantics" for kill/reset/throw as specified
in the Cadence proposal is the least surprising from the POV of the user.
I haven't heard anyone disagree with this point. Immediate semantics
are also (most likely) consistent with modeling languages such as UML state diagrams, etc.

I can think of numerous semantic issues if we don't have immediate semantics - e.g. what
happens if two perpetrators try to throw an exception in a victim process in the same
evaluation cycle. Do we guarantee which throw wins and which one loses ? Do we somehow
notify the loser that he has "lost".

I'd rather deal with any issues related to multi-threaded SystemC implementations when
the LWG is at the point of precisely defining such a thing. One option would
be to say that the behavior of kill/reset/throw is allowed to be different (and more
loosely defined) on such an implementation.

-Stuart

>-----Original Message-----
>From: Jeremiassen, Tor [mailto:tor@ti.com]
>Sent: Thursday, August 19, 2010 12:17 PM
>To: Bishnupriya Bhattacharya; Stuart Swan; Philipp A. Hartmann; SystemC P1666 Technical
>Subject: RE: Process Control Extensions - kill/reset/throw scheduling, exception handling
>
>I will just weigh in with a quick couple of comments.
>
>First, I agree that performance considerations are secondary for kill/reset/throw, as they will
>(should) not be common enough to impact the overall simulation time.
>
>On the other hand, I agree with Philipp that the semantics definition for kill is very restrictive. If
>there were a multi-core implementation of the SystemC simulator (which I think is something that is
>reasonable for the LWG to pursue), the requirement that:
>
>"No other processes shall execute between the time the kill() of a target process is ordered and the
>target obliges."
>
>will be impossible to enforce in any reasonable such implementation as the synchronization between
>schedulers running on different cores my only occur at the end of evaluation cycles. Thus it may not
>be possible to prevent processes from executing between the call to kill() and the end of the kill
>target process completing. On the other hand, I don't think we need to wait until the next evaluation
>cycle for the kill to take effect. Is there a way we can formulate this to allow for, in essence,
>multiple schedulers within a single simulator?
>
>Tor
>
>
>
>---
>Tor Jeremiassen, Ph.D.
>Simulation and Modeling CTO
>SDO Foundational Tools
>Texas Instruments Ph: 281 274 3483
>P.O. Box 1443, MS 730 Fax: 281 274 2703
>Houston, TX 77251-1443 Email: tor@ti.com
>
>|-----Original Message-----
>|From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-
>|technical@eda.org] On Behalf Of Bishnupriya Bhattacharya
>|Sent: Thursday, August 19, 2010 4:45 AM
>|To: Stuart Swan; Philipp A. Hartmann; SystemC P1666 Technical
>|Subject: 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.
>|

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