Re: P1666 surprising result with immediate notification

David,
 
 Re the thought experiment of allowing next_trigger in thread processes:
 
void P1() {
 next_trigger(ev1);
 ev1.notify();
 wait(ev2);
...
 
 would leave the above process P1 in the set of runnable processes as a result of the immediate notification. If ev2 happens to be notified in the same evaluation phase by the previous process to execute or by the next process to execute, and there happens to be another process sensitive to ev2, there are still no guarantees regarding whether P1 or P2 runs first.

Re the thought experiment of using std::set, it is perfectly allowable for a SystemC implementation to run that way. Tight immediate notification loops that effectively shut out other processes are perfectly possible.

So I do not see that you have uncovered any new problem.

Just my two cents.

Cheers,

John A

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

On Jan 17, 2011, at 7:21 PM, Philipp A. Hartmann wrote:
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).

Ah, I now understand. I think what I really did not understand was that static sensitivity for the current process would be active while it was running. Similarly, I would not have expected next_trigger to be considered until the return occurred. I can see benefits and dangers of this approach when it is understood.

This behavior almost makes the concept of next_trigger() notionally useful for SC_THREAD. Consider:

        next_trigger(ev);
        wait(ev);

This would notionally cause all the other processes in the current evaluation to execute before resuming the current process. Or would it? It would execute all unless in the selection of a next process, the current one were selected. The standard states (highlighting in red is my own):

5.2.1.2 Evaluation phase

From the set of runnable processes, select a process instance, remove it from the set, and only then trigger or resume its execution. Run the process instance immediately and without interruption up to the point where it either returns or calls the function wait or calls the member function suspend of a process handle associated with the process instance itself.
...
The order in which process instances are selected from the set of runnable processes is implementation defined. However, if a specific version of a specific implementation runs a specific application using a specific input data set, the order of process execution shall not vary from run to run.
Consider: What if the implementation used the semantics of std::set<T> to hold the set of runnable processes? This would not violate the letter of the standard. Recall that std::set<T> keeps members in sorted order. It would be legal for an implementation to examine the set from set<T>::begin(). Hence if the current process sorted to the beginning of the set, then it would be repeatedly executed with no intervening processes.

So we still have a problem, unless I am mistaken in the preceding paragraph.

Of course this behavior is quite surprising to any folks not familiar Verilog/VHDL because they don't have immediate notification. At very least, it would seem a large warning example would help in this case.

------------------------------------------------------
David C Black, System-Level Specialist
XtremeEDA USA Corporation http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL design assurance needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609

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