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

All,

I agree with John, that it may be too late in the process for P1666 to
change the immediate semantics of kill/throw/reset. I just wanted to
explain my original expectations in that regard.

Nevertheless, I think the open issues mentioned in my last mail need to
be addressed:

- Should an implementation be obliged to detect, when an application
  calls the scheduler (wait, etc.) during unwinding? Or if it even
  swallows kill/reset requests completely? (IMHO, yes)

  The current proposal states, that these cases "shall be illegal",
  but does not explicitly require an implementation reaction to it.

- Is a kill() issued from a method process meant to be immediate (i.e.
  blocking) in the same sense ? If we keep the immediate semantics, it
  should be the case, since otherwise we need to handle concurrent
  requests again.

    This is not implemented in the OSCI PoC simulator and an
  implementation of this seems to be quite difficult, from what I can
  see.

- Can we add a "bool sc_is_unwinding()", and a
  "bool sc_process_handle::is_unwinding()" to the proposal?
  (for a rationale, please see last mail)

Thanks,
Philipp

On 01/09/10 14:22, john.aynsley@doulos.com wrote:
> All,
>
> My opinion on this recent debate is pragmatic. The process control
> extension proposal has been around for a few years now and has been
> prototyped by Cadence and within the OSCI POC sim, and I assume it is
> fit-for-purpose. I am opposed to trying to re-engineer a "better" solution
> within the P1666 Working Group along the lines Phillipp suggests
> (regardless of whether Phillipp's arguments are valid).
>
> For what it is worth, I did find the immediate semantics of kill/reset to
> be "surprising", and would have expected them to work more like Phillipp
> suggests.
>
> I take seriously the possibility of re-engineering SystemC in the future
> to exploit many-core processing. However, IMHO the necessary changes will
> be so radical that the inclusion of the proposed process control
> extensions will make little difference.
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> Stuart Swan <stuart@cadence.com>
> Cc:
> "Jeremiassen, Tor" <tor@ti.com>, Bishnupriya Bhattacharya
> <bpriya@cadence.com>, SystemC P1666 Technical
> <systemc-p1666-technical@eda.org>
> Date:
> 27/08/2010 22:37
> Subject:
> Re: Process Control Extensions - kill/reset/throw scheduling, exception
> handling
> Sent by:
> owner-systemc-p1666-technical@eda.org
>
>
>
> Stuart, Bishnupriya, All,
>
> sorry, that I chime back in so late in the discussion, but I have been
> quite busy and out of office in the last couple of days.
>
> Please find some comments interspersed below.
>
> On 25/08/10 23:05, Stuart Swan wrote:
>
>> 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 agree, that users (including me) expect a kill/throw/reset to have an
> "immediate" effect on on the target. But I have indeed been quite
> surprised, that this extends to these operations being "blocking", i.e.
> are obliged to be completed when the calls return.
>
> - SystemC has simultaneity in terms of simulation time (and deltas)
> and is scheduled explicitly with a few modelling constructs. Why
> add implicit exceptions for kill/throw/reset?
>
> - sc_spawn is not "immediate" in this strong sense. The new process
> is only scheduled to run in the current evaluation cycle instead
> of being started already, when sc_spawn returns.
>
> - Usually, synchronous cancellation has to be set up explicitly
> (c.f. pthread_cancel).
>
> In short: I would have expected an effect in the same evaluation cycle
> without further guarantees. If a user is interested in the completion
> of a kill request, why not use a wait(h.terminated_event()) for this?
> Maybe a reset_event() could be useful as well.
>
> Moreover, in the currently available OSCI-internal implementation,
> kills issued from within a method process are not synchronised and
> return before the kill/reset/throw having any effect (see attached
> example). Otherwise, a method process could suddenly be blocked in the
> middle of its execution, which is certainly more surprising. So that's
> an inconsistency (or a bug in the implementation).
>
>> 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".
>
> Since the order of process evaluation is unspecified as of now, there
> is no need for any further guarantee here. My proposal would be to
> execute the requests in any order and react accordingly as currently
> defined (e.g. the second of two kills is a no-op).
> The only difference implementation-wise would be, that a queue (or any
> other container) of pending requests would be needed. Since these cases
> are quite likely modelling errors, we could consider to mark them as
> errors as well, though.
>
> Due to method processes having their kills delayed (see above), we
> already might need to handle these corner cases anyhow. Or we would
> need have to deal with preempted method processes, which I rather
> dislike and may be difficult to implement.
>
> [snip]
>>> |-----Original Message-----
>>> |From: Bishnupriya Bhattacharya
> [snip]
>
>>> |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.
>
> Agreed. Two points on this:
>
> Is an implementation obliged to detect, whether an application does not
> conform to the "rethrow and no scheduling" requirement? This is
> currently not defined in the proposal.
>
> Secondly, due to the obligation to avoid any scheduling during unwinding
> caused by a kill or reset, there's the need to detect this case from
> within destructors.
>
> As an example, we have proxy objects doing protocol/synchronisation
> stuff during construction and destruction. So there are cases, where
> SystemC scheduler calls are done inside a destructor. To avoid this
> during unwinding, something like
>
> bool sc_is_unwinding() {
> return sc_get_current_process_handle().is_unwinding();
> }
>
> would be needed, since one can't catch the current exception within the
> destructor during stack unwinding. With std::uncaught_exception a
> similar thing exists in the C++ standard library for related situations.
>
> 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.