Re: P1666 surprising result with immediate notification

All,

I agree with Philipp in every detail. That was the reason I added the
rewording to 5.2.1.2 para 4, the LRM change that first alerted David.
SystemC has been that way for years, so I agree with Philipp that we
should not mess with the scheduler rules at this stage.

Unfortunately SystemC differs from VHDL and Verilog in this respect, which
I did not fully appreciate back in 2005. So I propose making the necessary
clarifications now to the LRM.

Cheers,

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
Jerome CORNET <jerome.cornet@st.com>, David C Black
<dcblack@xtreme-eda.com>
Cc:
John Aynsley <john.aynsley@doulos.com>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
18/01/2011 01:21
Subject:
Re: P1666 surprising result with immediate notification

David, Jerome, All,

I'll try to give the immediate notification issue a shot. Firstly, a
summary of my understanding of the immediate notification semantics in
general.

 1) The kernel maintains a set of runnable processes for the (current)
    evaluation phase.

 2) Processes can be sensitive to events
    (either statically or dynamically, which is not important here).

 3) Upon immediate notification of an event, sensitive processes are
    immediately added to the set of runnable processes.

 4) If a process is already in the set of runnable processes, it's
    not added for a second time when triggered. It's a set ?

 5) If a process is activated, it's immediately removed from the
    set of runnable processes.

  Apart from the general dangers of immediate notifications, three
corner cases have been identified by David, which are all direct
consequences of the rules above:

?) Processes can be triggered immediately by themselves, resulting
   in multiple invocations in a single evaluation phase.

     To trigger itself immediately in the same evaluation phase, a
   process needs to be sensitive to the notified event _before_
   it calls ev.notify().

     The reason that this works at all is the removal of the process
   from the runnable set _before_ activating the process (5).

     The trigger can be due to a static sensitivity (as John pointed
   out), or due to a next_trigger(ev) in an SC_METHOD:

   // will trigger:
     next_trigger(ev);
     ev.notify();

   // won't:
     ev.notify();
     next_trigger(ev);

b) wait(ev) is not triggered from within the current process

   // won't trigger in the current evaluation phase
      ev.notify();
      wait(ev);

   I think, this is expected. The notification is _immediate_, which
   means, that all processes that are _currently_ sensitive to to event
   are triggered (3). The wait(ev) call has not been reached, yet.

   We should NOT change this rule, since this may well break existing,
   carefully coded models.

b) The number of activations of processes sensitive to immediately
   notified events can differ.

     This is a general artefact of immediate notifications. Their
   effect can depend on the kernel's internal scheduling order in
   which the set of runnable processes is activated.

     In David's example, one process is sometimes triggered twice in a
   row, depending on the instantiation order. The cause for this is the
   state of the set of runnable processes, when the event is notified.

   Consider the "repetition" case in the reference simulator
   (R being the set of runnable processes):

     start - R = {t2,t1}
     run t2 - R = {t1}
     run t1 - R = {} - notify ev - R = {t1,t2}
     run t1 - R = {t2} - notify ev - R = {t2,t1}
     run t2 ...

   Compared to:
     start - R = {t1,t2}
     run t1 - R = {t2} - notify ev - R = {t2,t1}
     run t2 - R = {t1}
     run t1 - R = {} - notify ev - R = {t1,t2}
     run t2 ...

  While I agree, that all of this can be quite surprising, I think we
should keep the rules as they are:

 · Immediate notification (3)(4) needs to be defined this way, to be
   actually immediate.
 · Self-triggering (especially with next_trigger) may be useful
   especially for method processes.
 · Process order dependence can not be avoided with immediate
   notifications.

Still, it may be helpful to refine the wording in that area.

Greetings from Oldenburg,
  Philipp

On 17/01/11 11:16, Jerome CORNET wrote:
[snip]
>
> *From:*owner-systemc-p1666-technical@eda.org
> [mailto:owner-systemc-p1666-technical@eda.org] *On Behalf Of *David C
Black
> *Sent:* Wednesday, December 15, 2010 10:11 PM
> *To:* P1666 Technical WG
> *Subject:* Fwd: P1666 surprising result with immediate notification
>
> [...]
>
> I see this is specified in the standard, but I contend it is very
> confusing and non-intuitive. Interestingly, *if you reverse the process
> registrations, the repetition goes away.* I imagine this could lead to
> some very hard to debug problems. Of course I routinely advise students
> to be careful with immediate notifications, but perhaps caution is not
> enough...
>
>
> [JC] Here what is the most confusing for me is the dependency on the
> process order registration... Either it should work whatever the order,
> or it should not work, but not a mix.
>
> My expectation was that *sc_event*::*notify*(*void*) would only affect
> those processes that are already have executed some form of *wait()* (or
> returned in the case of *SC_METHOD*). My internalized understanding of
> "static sensitivity" is that it is a sensitivity list created during
> elaboration and unable to change after that. The
> *sc_event*::*wait*(*void*) method is simply an *SC_THREAD*'s way of
> dynamically waiting on the statically specified list.
>
>
> [JC] Here I have to admit that I never fully understood the static
> sensitive thing. In my own way of thinking:
>
> SC_THREAD(ex2_thread1);
> sensitive << event;
>
> void ex2_thread1()
> {
> [...]
> wait();
> [...]
> }
>
> should be equivalent to:
>
> SC_THREAD(ex2_thread1);
>
> void ex2_thread1()
> {
> [...]
> wait(event);
> [...]
> }
>
> so I find very strange that the behavior of a process with respect to
> immediate notification differs depending on the way
> you actually wait for the event.
>
> Admittedly, it is problematic coding to have a process wait an event
> like this.
>
> Should the above behavior be allowed?
>
> Why does it happen (what is the mechanism)?
>
> Perhaps more importantly:
>
> * Is this behavior expected?
> * Is there a good application of this behavior?
> * Is this unavoidable?
>
> [JC] I won?t say that using this is proper coding or whatever, but I
> have already seen a somewhat ?good? application of ?this behavior? (by
> ?this behavior?
>
> I mean: ?a process can notify immediately an event, then wait() for it
> just after that and be predictably awaken in the same evaluation phase
> whatever the process declaration order is?).
>
> The application in question was the possibility to implement a pure
> ?yield? in SystemC, for research purposes (but this can have
> applications for real platforms).
>
> A yield is a base construct in cooperative scheduling, that allows a
> process to relinquishes control to the scheduler. In SystemC, we don?t
> have ?pure? yield
>
> constructs, in the sense that only wait() is doing such effect, and this
> is always associated with an event or a time. Sometimes, you just want
> the currently executing
>
> process to execute again in the very same evaluation phase ?later? (that
> ?later? can be ?immediately? or after the last process or whatever).
>
> So the only way I know how to implement a pure yield() without modifying
> the kernel (and being out of the norm by the way), was the immediate
>
> notification-then-wait() trick.
>
>
> I don?t have a strong opinion, but I think that forbidding this practice
> or taking action so that it no longer work in subsequent SystemC
> versions would at least prevent people to emulate a pure yield() call.
> I concur with you that dependency on the process registration order
> in your example should not appear, and so if we choose to keep
> the behavior we would have to spell it more clearly and to have
> compliant implementations.

-- 
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.