RE: P1666 surprising result with immediate notification

Hi David,

and sorry to jump late to this discussion.

Answers below.

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.

Regards,

Jerome

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