Re: P1666 surprising result with immediate notification

Tor,

I agree that a parallel implementation needs to ensure that no process
is running concurrently with itself.

  But IMHO, this is not directly related to the semantics of the wait(),
next_trigger(), notify(), and sensitivity rules of SystemC.
An implementation is free to postpone the update of the run queue after
a process has yielded. The application would not see the difference,
since it is still in the same evaluation phase.

  Of course, immediate notification itself is even more dangerous in a
parallel simulation than before.

Greetings from Oldenburg,
  Philipp

On 19/01/11 00:24, Jeremiassen, Tor wrote:
>
> The ability to re-trigger a method/thread while it is still running seems a little dangerous to me. While I can see some uses for it as SystemC exists today, preserving these semantics as we eventually move to a parallel implementation of SystemC will make things more complicated, either from a semantics point of view or from a simulator implementation point of view.
>
> Allowing the immediate re-activation of a method or thread by adding it to the run queue while it is still running could in a parallel implementation cause it to run concurrently with itself, which typically would not be the desired outcome. In fact, based on OS scheduling, you have a race condition between the two instances of the process as to which would complete first. Preserving this self-rescheduling semantics would necessitate either a mutex on each process to prevent such concurrent execution, or not allowing instances of a process to execute on different cores, either of which would increase the simulator overhead.
>
> If this functionality is used in a backdoor way to implement specific "missing" features of SystemC (like "yield"), it would be better to explicitly provide the desired functionality in its limited form than to provide "abusable" semantics.
>
>
> |-----Original Message-----
> |From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-
> |technical@eda.org] On Behalf Of Philipp A. Hartmann
> |Sent: Tuesday, January 18, 2011 12:20 PM
> |To: john.aynsley@doulos.com; bpriya@cadence.com
> |Cc: David Black; P1666 Technical WG
> |Subject: Re: P1666 surprising result with immediate notification
> |
> |Bishnupriya, John, All,
> |
> |I haven't been aware of the corner case Bishnupriya has raised in her
> |last mail that threads may be immediately triggered by their static
> |sensitivity even though they yield with an explicit wait(ev), with ev
> |not being part of the static sensitivity. I agree, that this is
> |definitely bad.
> |
> | Therefore, I agree that we should change the rules that static
> |sensitivity is not considered while the process is running (similar to
> |Verilog).
> |
> | Using next_trigger as it is now (having an effect depending on the
> |order of statements in the body) feels consistent to me. Moreover,
> |within an SC_METHOD a re-trigger could be used for the modelling of
> |complex explicit state machines.
> |
> | I have the feeling that changing wait(ev) to have immediate effect
> |could break existing models, since then suddenly processes may be
> |re-triggered that currently are guaranteed to miss the notification.
> |This is one of the few things you can rely on with the current immediate
> |semantics.
> |
> | When prohibiting self-triggers via the static sensitivity _and_ an
> |immediate wait(ev), we effectively remove the possibility to trigger a
> |thread process from within itself. I don't think that this is a
> |show-stopper, since in SC_THREADs you can always skip the wait and
> |continue their work directly. They can't rely on any process being run
> |in-between anyhow.
> |
> | That said, I would propose to keep the notify() call as it is now, in
> |the sense that it continues to respect the static sensitivity to avoid
> |breaking existing models that somehow rely on this. But we should
> |deprecate this function in favour of a notify_immediate() function, that
> |clearly expresses the intent and can safely follow the new rules.
> |
> | I always found it unfortunate, that one can accidentally use the
> |dangerous immediate notification mechanism so easily. Having an
> |explicit notify_immediate() could be an additional benefit.
> |
> |My 2¢,
> | Philipp
> |
> |On 18/01/11 20:26, john.aynsley@doulos.com wrote:
> |> Bishnupriya, All,
> |>
> |> Back in 2005 I had assumed that neither a method process nor a thread
> |process would have the capability to be sensitive to anything while the
> |associated function was actually running, because that is how Verilog
> |behaves (which does have immediate notifications). In other words, for a
> |thread, I assumed the rule you described below. For a method, I assumed
> |next_trigger() created the next trigger condition, but that the method
> |process would not become a candidate to be triggered until it had returned
> |control to the kernel.
> |>
> |> So I think we have 3 sets of rules on the table:
> |>
> |> * The "Verilog rules" (which was the intent of the 1666-2005 LRM,
> |although not spelled out very explicitly)
> |> * The de facto PoC sim behavior
> |> * Bishupriya's rules
> |>
> |> My view on this is not principled, but purely practical. Do we fix the
> |PoC simulator, or do we fix the rules? Is there code out there that relies
> |on the current PoC scheduling rules? My default position would be that we
> |have to document the PoC behavior, though I think that adopting the Verilog
> |rules would lead to the fewest surprises. I think we might argue the case
> |on the grounds of harmonisation between languages.
> |>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.