RE: P1666 surprising result with immediate notification

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

From:
Jerome CORNET <jerome.cornet@st.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, David Black
<dcblack@xtreme-eda.com>, Philipp A Hartmann <philipp.hartmann@offis.de>,
Bishnupriya Bhattacharya <bpriya@cadence.com>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
19/01/2011 11:26
Subject:
RE: P1666 surprising result with immediate notification

John, All,
 
 
From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
john.aynsley@doulos.com
Sent: Wednesday, January 19, 2011 10:56 AM
To: David Black; Philipp A Hartmann; Bishnupriya Bhattacharya; P1666
Technical WG
Subject: RE: P1666 surprising result with immediate notification
 
All,

One plank of SystemC is the co-routine semantics. The more I think about
it, the more I think that the PoC behavior is an anomaly. A running
process should not notice an immediate notification to itself.
[JC] I agree in general with you except for the example of yield()
implementation I gave you where it is not possible to do without.
I concur with Tor?s proposal of adding a yield() function then. If we had
such function, I see little reason
to keep immediate self notification for the future.

I would vote for

* Keeping the PoC behavior as it is (for backward compatibility)
* Deprecating any immediate notification of an event to which the calling
process is statically sensitive or already sensitive using next_trigger.

* An immediate notification of an event to which the calling process is
not statically sensitive but is subsequently made sensitive using wait(ev)
or next_trigger(ev) is permitted
[JC] Just to be sure, in that latter case would the calling process be
awaken by that previous notification? (I guess no?)

Jerome
 

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