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.