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, and is believed to be clean.Received on Tue Jul 20 07:12:35 2010
This archive was generated by hypermail 2.1.8 : Tue Jul 20 2010 - 07:12:37 PDT