Re: P1666 surprising result with immediate notification

Philipp, Jerome,

This is all good stuff, but since we have already punted process
priorities and process parallelization to the LWG, I guess we should punt
yield() to the LWG as well. I am not opposed to introducing yield at some
stage.

I keep with the proposal to clarify the LRM to enforce the "Verilog
semantics" and to deprecate all cases where a running process is required
to notice an immediate notification send from itself (preferably with a
warning from the PoC Sim)

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com, Jerome CORNET <jerome.cornet@st.com>
Cc:
Bishnupriya Bhattacharya <bpriya@cadence.com>, David Black
<dcblack@xtreme-eda.com>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
19/01/2011 14:59
Subject:
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
[attachment "yield.cpp" deleted by John Aynsley/doulos] 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.