RE: Process Control Extensions

Hi Bishnupriya,

Yes, you understand my tentative proposal correctly.

I would just make the further point that under my proposal, the process
control extensions can indeed be considered orthogonal. But the motivation
for my proposal is that without it, the process control extensions have an
implementation dependency that may be more significant than the current
implementation dependency regarding process termination in 1666-2005.

Specifically, consider:

h1.kill(SC_INCLUDE_DESCENDANTS);

Suppose your intent were to kill the entire process tree below h1, even if
some individuals, which may be parents of other processes, had already
terminated and been deleted. Without my proposal, the above call could not
be relied upon to kill all descendants in every SystemC implementation,
which might have critical functional consequences, in which case to be
portable an application would have to keep track of descendants itself (by
building some explicit list of processes). Prior to the introduction of
process control extensions there was no construct in SystemC that
explicitly involves all descendants of a process, so the issue did not
arise directly (only indirectly if someone coded a recursive traversal
using get_child_objects()).

I'm not wedded to this proposal. Am I missing something?.

Thanks,

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, Neeti
Bhatnagar <neeti@cadence.com>
Date:
25/05/2010 04:57
Subject:
RE: Process Control Extensions

John,
 
First, I would like to clarify If I understand you right, and then comment
on my position later.
 
What you propose below is essentially changing what the LRM says today
about what should happen when a process terminates.
 
Today the LRM leaves it upto the implementation - it can choose to delete
the process object or not, it can choose to invaldiate associated process
handles or not.
 
What you propose is that the LRM mandates when a process object
terminates, and it has any live children (actually live descendants by
applying this rule recursively), it is obligated to
 
1) not delete the process object
2) not invaldiate any associated process handles
 
In my mind, this can be considered orthogonal to the process control
extensions, and can simply stand on its own as a modification to the LRM.
The connection to the process control extensions is that this change
provides a clean/unambiguous definition of "descendants" of a process
handle, which benefits the include_descendants clause in the process
control constructs.
 
Does this correctly interpret your proposal?
 
Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, May 24, 2010 5:50 PM
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: RE: Process Control Extensions

Bishnupriya,

That is not quite what I had expected you to say, so we need to look a bit
deeper 8=)

I had expected you to say that the specification of include_descendents
was independent of whether or not an implementation chooses to invalidate
process handles so that include_descendents would always find all living
descendents, direct or indirect, regardless of whether any intermediate
process objects had been deleted or process handles invalidated. You seem
to be saying that whether or not an implementation chooses to invalidate
handles can have an effect on the set of processes found by
include_descendents.

Thinking about it, a similar point applies to
sc_process_handle::get_child_objects. We say that get_child_objects
excludes deleted process objects, but that an implementation can choose
whether or not to invalidate process handles and delete process objects
for terminated processes. In summary, we have:

* process terminates => implementation can choose whether or not to
invalidate process handle
* valid handle => process object still exists
* invalid handle => implementation can choose whether or not to delete
process object
* get_child_objects could return a terminated process object with valid or
invalid handles
* get_child_objects excludes any deleted process objects

From the above, it is in general implementation-defined whether a process
can find its living grandchildren (because its children may have been
deleted).

It would make more sense to me if an implementation were NOT ALLOWED to
invalidate a process handle or delete a process object while that process
still has living children. It is one thing for the retrieval of dead
children to be implementation-defined (sorry to be so morbid), but quite
another for the retrieval of living grandchildren to depend on the
implementation. What do you think?

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
17/05/2010 08:02
Subject:
RE: Process Control Extensions

John,
  
The process control extensions do not impose any additional constraint on
the validity of process handles over and above what the LRM already
specifies. Currently the LRM says
  
"When the underlying process instance terminates, an implementation may
choose to invalidate any
associated process handles but is not obliged to do so. In other words,
when a process terminates, an
implementation is neither obliged to keep the handle valid nor to
invalidate the handle."
  
In your example, after B terminates, if a process control extension is
invoked on A with the include_descendants clause, one of two things can
happen
  
1) if an implementation invalidated process handles associated with B as
soon as B terminated, the process control extension will not be able to
find B or C as decendants of A, and will not apply to B and C.
  
2) if an implementation kept the process handles associated with B valid
after B terminated (say beacuse it had live children), the process control
extension will be able to find B and C as descendants of A and will also
apply to B and C.
  
An implementation need not to do anything special to choose 1) or 2). It
should automatically fall out - note that
sc_process_handle::get_child_objects() returns an empty vector if the
handle is invalid.
  
Does this clarify the intent?
  
Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, May 14, 2010 4:42 PM
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: RE: Process Control Extensions

Bishnupriya,

* Is include_descendants intended to find descendents of intermediate
processes that have already terminated, i.e. children of dead children?
[bpriya> yes, it is. Note that the process on which the construct is being
called can itself be terminated, then the construct applies to its
descendants - the same logic holds for an intermediate process in the
sub-hierarchy that has terminated.]

Can you please clarify? Suppose process A spawns process B and B spawns C,
and suppose process B is terminated first before A or C. You say that
include_descendents on A should find C. Is this meant to imply that the
implementation is obliged to keep the process handle for the terminated
process B valid until after all its children have terminated, or is an
implementation permitted to invalidate any handles to B while B still has
surviving children? Would this be implementation-dependent?

Thanks,

John A

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