RE: P1666 surprising result with immediate notification

Jerome,

Agreed! Our emails crossed 8=)

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>,
"john.aynsley@doulos.com" <john.aynsley@doulos.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 15:11
Subject:
RE: P1666 surprising result with immediate notification

Philipp,

good point!

I would not be against introducing a sc_yield() method (hence my
proposal), which would not be that
complex to define, but I guess we are no longer at the stage of
introducing new features.
If you are opposed to the feature, let's leave that for a subsequent
version of the norm.

Sorry for the (involuntary) mess,

Jerome

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Wednesday, January 19, 2011 3:59 PM
To: john.aynsley@doulos.com; Jerome CORNET
Cc: Bishnupriya Bhattacharya; David Black; P1666 Technical WG
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
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.