RE: suspend vs disable

John,

I've been thinking about this and arrived at the conclusion that the process control spec will benefit from additional insights over and above its current content, especially in these corner cases - like the one you mention below, where a process is already scheduled and then it gets suspended and resumed before it gets a chance to run.

I've discussed with Stuart also, and we are on the same page.

The additional content will be a sub-section "Scheduling Insights" added to the end of Section 2. I will be sending this out by end of the week.

Note that this is apart from the current discussions we're having in this forum which also is refining the spec further, as intended.

Thanks,
-Bishnupriya
________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, July 21, 2010 8:00 PM
To: Bishnupriya Bhattacharya
Cc: Stuart Swan; systemc-p1666-technical@eda.org
Subject: RE: suspend vs disable

Bishnupriya,

Thanks. That is all clear, and I agree with your conclusion that the semantics you have chosen are clear and consistent.

When discussing suspend-resume, you say "It is intuitive in this case that the process will execute as soon as resume() comes in." But is it not the case that resume() only causes the process to become runnable in the following evaluation phase? Consider
proc.suspend();
proc.resume();
If the target process was runnable, it will be removed from the set of runnable processes and moved to the next delta cycle, right?

As an aside, I was struck by a couple of your sentences in the sense that they do not match the way the scheduling algorithm is formulated in the LRM. You say "The LRM does not define the process's effective sensitivity when it is in this state of transition." I see things differently:

- There is a set of runnable processes

- If a process is already runnable, an attempt to insert it into the set again is ignored (it is a mathematical set)

- A process does not manage its own sensitivity or consume sensitivity. Rather, the scheduler has rules for what it does with notifications and time-outs

- When the scheduler deals with delta notifications and timed notifications, it does so by adding processes to the set of runnable processes. That is "consuming sensitivity"

- A process that is already runnable could indeed be sensitive to an immediate notification, in which case it simply stays runnable

- A process that is currently running cannot be interrupted, so the kernel cannot deal with delta or timed notifications, but an immediate notification could cause the currently executing process to be put back into the set of runnable processes. (This is a clarification to the LRM that I've spelled out as part of the current round of revisions)

- There is a corner case where an immediate notification occurs and the currently running process only makes itself sensitive to the event later in the current evaluation phase (by calling wait(event)). This case is handled under the above rules.

It's all cool.

John A

From: Bishnupriya Bhattacharya <bpriya@cadence.com>
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Stuart Swan <stuart@cadence.com>
Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date: 20/07/2010 22:51
Subject: 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.