RE: suspend vs disable

John,

Comments below.

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Tuesday, July 20, 2010 6:42 PM
To: Bishnupriya Bhattacharya; 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?
[bpriya: right. it will wait for resume_event, i.e. it will execute as soon as it is resumed]
- that a runnable process that gets suspended by another process shall be removed from the set of runnable processes?
[bpriya: the semantics is:
  - the suspended process will consume the triggering that caused it to get scheduled
  - it will then wait for the resume_event
  - effectively it will not run now but it will consume its sensitivity triggering and will execute as soon as it is resumed]

suspend shall cause a method process to suspend only after the associated function has returned
[bpriya: right; for its next triggering the method needs to see its effective sensitivity, AND the resume_event]

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?
[bpriya: yes]
- is it the same as or different to a suspended process in this respect?
[bpriya: different]
- at the end of the current evaluation phase?
- what if the disabled process gets re-scheduled later in the current evaluation phase?
[bpriya: it won't run because it has been disabled]
- in other words, is a disabled process barred from executing again in the current evaluation phase?
[bpriya: a disabled process completes one execution if it is already scheduled or already executing, after that it does not run until it is enabled, and its effective sensitivity is triggered.

The intution behind these semantics comes from how the effective sensitivity of a process is defined and the difference between suspend & disable.

Conceptually, disable() saves the effective sensitivity of the process for later, then NULLs its effective sensitvity so that the process does not run anymore - enable() restores the process's effective sensitivity to what it was before the disable() happened. Then the question is: what is a process's effective sensitivity when it is sitting on the runnable q, or when it is in the middle of its execution? The LRM does not define the process's effective sensitivity when it is in this state of transition. Hence it is more well defined to let the process complete this transition, i.e. finish one execution, and in that process define the effective sensitivity for its next run, and then have the disable take effect. Note that in the OSCI implementation, the effective sensitivity of a process in this state of transition is set to its static sensitivity, but that is just an implementation artefact - a thread process often does not even have any static sensitivity.

If we compare to suspend-resume, the semantics above of disable-enable is different. If a process is sitting in the runnable q and is suspended, or if a thread is in the middle of execution and suspends itself, then it is immediately suspended; however in this case the semantics makes sense - the process consumed its effective sensitivity and is now suspended, pending resume_event. It is intuitive in this case that the process will execute as soon as resume() comes in. When a method suspends itself, it may have already set up its effective sensitivity for the next run (thru next_trigger call) - its consistent to let the method run to its end, and since the effective sensitivity is already set, we don't want to discard it, but AND it with resume_event for its next run.

This suspend/disable semantics of what happens if the process is currently scheduled or alredy running, is somewhat confusing. I've given considerable thiought to this, and the current rules appear to be the most consistent - i.e. not likely to surprise the user. I've thought about alternatives, but not come up with any good ones. For example, suppose for disable, we chose the rule that if a process is already scheduled, we will remove it from the runnable q. Then, how would it become runnable again? As soon as enable() comes? Not right because enable() is not supposed to immediately execute a process - it always waits for its effective sensitivity to trigger, which is the key differentiator with resume(). But then what is the process's effective sensitivity after being removed from the runnable q? It has already "consumed" its last triggering by being put on the runnable q, but did not get the chance to run and define its effective sensitivity for the next triggering. If we go with the OSCI implemenation, its effective sensitivity is defined as its static sensitivity, but that is really an arbitrary choice - the user may well be surprised that the process is waiting for its static sensitivity after the enable in order to run - note that threads usually do not even have any static sensitivity. Also note that the senisitivity triggering that caused the process to be put on the runnable q is getting "lost" - it got consumed but did not cause the process to run now, nor did it contribute to the process's running later after the enable.

Let me know if you see a better way of nailing down the semantics here.]

Thanks,

John A

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