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.