Re: suspend vs disable

Speaking for myself, we should consider multi-processor safe definitions especially as we refine disable & suspend.

With inter-thread communication via signals, we are a long way toward MP safe semantics; and given the language as a synthesis target, we already have the concept of varying speeds of execution of a collection threads to deal with.

At minimum, given the thrust to complete 1666-2010 this year, we should just list the things we should consider in the future in the language to make it MP safe.

What are the known problems?

As Tor says, let's be careful not to make new problems.

Mac

________________________________
From: owner-systemc-p1666-technical@eda.org <owner-systemc-p1666-technical@eda.org>
To: Jeremiassen, Tor <tor@ti.com>
Cc: systemc-p1666-technical@eda.org <systemc-p1666-technical@eda.org>
Sent: Tue Jul 20 08:51:17 2010
Subject: 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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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