Re: P1666 surprising result with immediate notification

John, Jerome,

Is it really necessary to have a yield() function in the core language?
We should at least choose a less conflicting name, like sc_yield(), if
we consider to allow this from within channels etc. as well.

  If there's a valid use case for such a functionality (which I don't
see yet), an implementation can easily build it on top of the existing
(and proposed) immediate notification semantics already.

All you need are two events and a "pingback" method process:

  sc_event yield_request_event, yield_ack_event;

  SC_METHOD(yield_pingback);
    sensitive << yield_request_event;

  void yield_pingback() { yield_ack_event.notify(); }

  void yield() // will return in the current evaluation phase!
  {
    yield_request_event.notify();
    wait( yield_ack_event );
  }

  In a small example attached to this mail, a PoC class
'sc_utils::yieldable' is defined that you can inherit in addition to
sc_module to have a yield() available in your module.

  What's not possible with this implementation is a yield() from within
an SC_CTHREAD, though. But this is also not possible with the current
(broken) notification semantics, right?

Greetings from Oldenburg,
  Philipp

On 19/01/11 12:41, john.aynsley@doulos.com wrote:
> Jerome, All,
>
> Consider the following definition:
>
> void yield(); can be called from a thread process only. (Clocked
> thread???). It is like a wait in the sense that it yields control to the
> kernel, but unlike a wait in the sense that it also adds the yielding
> process to the set of runnable processes in the current evaluation phase.
>
> Of course, the difficulty in SystemC is that the scheduler is not fair, so
> the process in question might be the very next process to be selected by
> the scheduler, and so on ad infinitum as long as the same process keeps
> calling yield. Without some other modification to the scheduling
> algorithm, such a yield does not seem very useful in SystemC as it stands.
> (I am not opposed to us considering such modifications)
>
> Cheers,
>
> John A

[snip]

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