RE: suspend vs disable

Tor,

Well, I seem to remember we agreed a while back that we were not going to
mess with the existing non-preemptive scheduling semantics of SystemC. The
EDA vendors, at least, do not seem ready to discuss standardization of
multicore SystemC just yet.

John A

From:
"Jeremiassen, Tor" <tor@ti.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, "bpriya@cadence.com"
<bpriya@cadence.com>, Stuart Swan <stuart@cadence.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
20/07/2010 15:12
Subject:
RE: suspend vs disable

John,
 
Would it make sense to consider the implications of these definitions on a
possible future truly concurrent implementations of SystemC on multi-core
systems? In particular, should we try to make the semantics such that they
would be reasonable to implement in the presence of possibly multiple
queues of runnable processes and synchronization/communication lag between
the different cores? Not that we should need any major changes, but since
the devil is in the details, it would be nice to try to avoid any problems
down the road.
 
Best regards,
 
Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com
From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of 
john.aynsley@doulos.com
Sent: Tuesday, July 20, 2010 8:12 AM
To: bpriya@cadence.com; Stuart Swan
Cc: systemc-p1666-technical@eda.org
Subject: suspend vs disable
 
Bishnupriya, Stuart, 
Please confirm the intent: 
suspend shall cause a thread process to suspend immediately, meaning 
- that a thread process that suspends itself shall not return from 
suspend? 
- that a runnable process that gets suspended by another process shall be 
removed from the set of runnable processes? 
suspend shall cause a method process to suspend only after the associated 
function has returned 
disable shall cause a thread or method process to get disabled when, 
exactly? 
- after the thread process has yielded control or the method process 
returned? 
- is it the same as or different to a suspended process in this respect? 
- at the end of the current evaluation phase? 
- what if the disabled process gets re-scheduled later in the current 
evaluation phase? 
- in other words, is a disabled process barred from executing again in the 
current evaluation phase? 
Thanks, 
John A
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.