RE: Process control issues

John,

I've just finished my review of the LRM draft, and the process control constructs section did not satisfy me. There are a few technical nits, but those are not important - the main issue is that no intuition is provided behind the constructs, making it hard for readers to digest/understand. I feel more examples and more rationale/intuition is definitely necessary for readability.

I'll send my specific feedback in a separate email. Comments on your questions below.

Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Tuesday, January 11, 2011 7:27 PM
To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org; Stuart Swan
Subject: Process control issues

Bishnupriya, Stuart, All,

The largest number of issues concern the process control extensions, either pointing out ambiguities or asking for clarification. I will group together all of the issues in this single email. Please review my answers below, and give me your take on the open issues.

Thanks,

John A

[Philipp]
5.4.2 end_of_elaboration (2nd enum, (d))

 With the unification of SC_THREAD and SC_CTHREAD, is there still a reason to explicitly forbid SC_CTHREAD during end_of_elaboration? It certainly works with the reference simulator.

[bpriya: I won't term it as unification of SC_THREAD, and SC_CTHREAD; the process control constructs make SC_THREADs be a superset of SC_CTHREADs, such that SC_CTHREADs could be deprecated. But as long as SC_CTHREAD is there, it is distinct from SC_THREAD, and legitimately falls under a different category. For this particular case, I don't feel strongly, but am more inclined to retain current behavior, where SC_CTHREAD is not allowed in this callback.]

[Bart]
6.6.6.1: resume: what if a method resumes itself when executing the associated ftion till the end after a suspend call? Same for enable

[bpriya: Excellent question. If I understand it right, the q is if a method process suspends itself, and then continues to execute till end, and while running, also resumes itself, what happens? Similarly for disable/enable. The answer is nothing happens. i.e. the suspend-resume and disable-enable cancel each other out. To cover this case, it will be good to add clarification to LRM. Currently it says, "If a method process suspends itself, the associated function shall run to the end before returning control to the kernel". Add "After control is returned to the kernel, the suspension takes effect, unless the method process resumes itself in the course of running to the end of its function". Current text says "If a process disables itself, whether it be a method process or a thread process the associated function shall continue to run to the point where it calls wait or to the end before returning control to the kernel." Add "After returning control to the kernel, the disable() call takes effect, unless the process enables itself in the course of running to the point where it calls wait or to the end".

[Alan]
6.6.6
I'd like to have a simple summary of the process control functions in the introduction, e.g. what they are (each pair) and the intent behind the use of each pair. Perhaps just Table 2 in section 6.6.6.4 would be ok?

        [JA] I would like to spend some time improving the process control documentation.
[bpriya: this is necessary.]

[Hiroshi]
5 6.6.6.1 p.74
"The following cases of calling ""resume"" do not seem to be descrived clear.
(1) If ""resume"" are called multi processes at the same simulation time, what happens?

        [JA] If h.resume() is called from multiple processes, the process associated with h is resumed only once ("resume on a process that is not suspended shall have no effect"). If multiple processes are resumed, they all become runnable in the same evaluation phase (in arbitrary order)

[bpriya: agreed]

[Hiroshi]
(2) If ""suspend"" and ""resume"" are successively called to the process during wait, when does it become runnable? For example, wait(100) -> calls ""suspend"" after 10 ns -> calls ""resume"" after 50 ns, then does process become runnable after 40 ns?"

        [JA] See the 1st para describing resume. The sensitivity of the process would NOT have caused it to become runnable while it was suspended, and hence the process will NOT become runnable when it is resumed.

[bpriya: I'm not sure I understand the q. Your answer is correct, but if the question is - after wait(100), if suspend is called at 10 ns, resume() at 60 ns; does process run at 100 ns - the answer is yes.

[Hiroshi]
7 6.6.6.1 p.74 - 75 The difference between suspend/resume and disable/enable is difficult to understand from the explanation in the LRM. Use cases can be helpful to understand these functions and purposes.

        [JA] I agree the difference between suspend/resume and disable/enable is difficult to understand, as are the semantics of process control in general. I could spend some time including further examples in the LRM. I could also spend some time writing an introduction to the process control methods and clarifying the rules, since I am not particularly satisfied with the text as it stands.
[bpriya: I feel an example here is particularly necessary with clocked processes to show the distinction, as also a written explanation.]

[Hiroshi]
9 6.6.6.4 p.81 Table 2
The "enable" row of Table 2 shows "The current evaluation phase". Is this correct? Should it be "The next evaluation pahse"?

        [JA] It is correct, but it has to be read in the right context. The earliest time at which a call to enable() can affect the target process is indeed in the current evaluation phase. For example, a subsequent immediate notification within the current evaluation phase could make the target process runnable in the current evaluation phase. On the other hand, the earliest time at which a call to disable() can affect the target process is the next evaluation phase (the phase following the current evaluation phase).
[bpriya: agreed]

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