P1666 review issues from Bishnupriya

Bishnupriya,

Here is my response to your review issues.

My comments are marked [JA] below

John A

1) pg 17:
"5.2.1.2 Evaluation phase
CLARIFICATION: From the set of runnable processes, select a process
instance, remove it from the set, and only then trigger or resume its
execution. Run the process instance immediately and without interruption
up to the point where it either returns or calls the function wait
ADDITION: or calls the member function suspend of a process handle
associated with the process instance itself."
 
The last addition is not completely true. If a method process suspends
itself, it still continues to the end.

[JA] Agreed. Good catch. Fixed.

2) pg 73, "If the include_descendants argument has the value false,"...
 
This should say if include_descendants has the value SC_NO_DESCENDANTS

[JA] Agreed. Fixed.

 
3) more examples are needed for process control; they are rather cryptic
otherwise.
Need to provide intuition behind difference between suspend-resume and
disable-enable using clocked threads example

[JA] Agreed. I will work on this, given time.

4) pg 75 "By the process instance being resumed while it is in the
synchronous reset state"
 
Here and elsewhere, is there scope for confusion with process control
construct resume()? Can some other word be used?

[JA] The issue is that the terms "resume" and "resumed" are already firmly
established in the LRM to describe what happens when a process awakes. I
tried to deal with this by editing the glossary entry for "resume". I am
not opposed to working on a better solution, but no obvious one springs to
mind. I suppose I could try to replace resume by wake up, resumes by
awakes, resumed by awoken, and so on.

5) pg 77, reset() mentions "sc_unwind_exception may be caught provided it
is immediately re-thrown."
 
This should be moved to kill(), as that is where the concept is first
introduced.

[JA] For starters, I will replicate this statement under "kill". But I
would like to try to restructure the descriptions of kill, reset, and
sc_unwind_exception altogether.

6) pg 77, "Calling reset before the process has first executed is
permitted, but shall have no effect."
 
Is this true? Shouldn?t reset() notify the event returned by
reset_event()?

[JA] Good question. I wrote this statement before we added reset_event.
Quote: "The reset event shall be scheduled using an immediate notification
in the evaluation phase in which the explicit or implicit call to reset
occurs."
Quote: "it shall be an error to create an immediate notification during
elaboration or from one of the callbacks before_end_of_elaboration,
end_of_elaboration, or start_of_simulation."
That seems to infer that if reset() is called prior to the initialization
phase, the reset_event() should indeed not be notified. If this is the
case, it needs to be noted in the LRM. What about if reset() is called
during the initialization phase but before a process has first executed?

7) pg75, 76, "A process instance can be reset in one of three ways
 
- By a call to member function reset of a process handle associated with
that process instance, which
shall reset the underlying process instance immediately
- By the process instance being resumed while it is in the synchronous
reset state
- By a reset signal specified using async_reset_signal_is attaining its
reset value, at which time reset
shall be called (see 6.2.13)"
 
For the 2nd bullet should mention reset_signal_is also ... "which can
happen by a reset signal specified using reset_signal_is attaining its
reset value".

[JA] Note that the term "synchronous reset state" is defined 6 lines down.
Do you still think it necessary to elaborate point 2?

 
8) pg 79, "If a process throws an exception to itself, then on return from
throw_it, control shall pass to a catch block in that function."
 
The throw_it() call does not really return, within that call the exception
is thrown, so maybe it?s better to say "if a process throws an exception
to itself, the throw_it() call shall never return, and control shall pass
to a catch block in the function".
 
[JA] Agreed. I will change the wording.

9) pg 82, "When called during simulation, sc_get_current_process_handle
shall return a handle to the currently executing spawned or unspawned
process instance, if any. If there is no such process instance,
sc_get_current_process_handle shall return an invalid handle.
CLARIFICATION: When called from sc_main, sc_get_current_process_handle
shall return an invalid handle."
 
The last line intends to say that when called from sc_main *during
simulation*, sc_get_current_process_handle shall return an invalid handle.
It?s probably best to spell that out explicitly to eliminate any chance of
confusion.

[JA] Okay. That begs the question of what should happen when
sc_get_current_process_handle is called from sc_main during elaboration. I
guess we want the same rules as for the callbacks above, right?

10) pg 126, "sc_object& operator= ( const sc_object& );
The assignment operator shall not modify the hierarchical name or the
parent of the destination
object in the object hierarchy. In other words, the destination object
shall retain its current position in the object hierarchy. Attributes and
children of the destination object shall not be modified. operator= shall
return a reference to *this."
 
I?m sure this has been discussed and I don?t remember, but what is the
rationale for this operator=? If all these properties are not modified,
then what is modified? It will benefit the reader I think to include the
rationale here.

[JA] See Philipp's explanation

11) pg 412, "The enumeration sc_verbosity provides the values of
indicitive verbosity levels that may be passed"...
 
Typo should be ?indicative?.

[JA] Fixed.

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