RE: Process Control Extensions

Philipp,

I agree with Bishnupriya's comment below.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
Cc:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
25/05/2010 15:27
Subject:
RE: Process Control Extensions

Philip,

You are right that the LRM currently does not specify the definition of an
object's parent when that object's original parent process terminates.

Your proposal is certainly a possibility. However, I much prefer the
alternate that John's proposal implies. Thinking from the user's
perspective, suppose the user was looking at the process hierarchy in a
GUI tool, and the middle process dies (B in John's example). It seems most
intuitive to me that when this happens the GUI refreshes to just gray out
B, but the hierarchy remains unchanged. I find this much more cleaner and
natural than the processes changing around their parents.

Also I do not think that John's proposal is difficult to specify. Rather,
the property that an object's parent does not change during it's lifetime
seems desirable and easy to understand.

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Tuesday, May 25, 2010 7:34 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
Subject: Re: Process Control Extensions

John, Bishnupriya,

I think, it might be quite difficult to specify the rules for deletion (or
invalidation of handles) in this case.

  But there might be an alternative: Couldn't we just define what happens
to child processes (and other objects), if a parent process (or
object) gets deleted / removed from the hierarchy? I think, this is
currently not specified by the LRM at all, right?

  The OSCI implementation currently moves such orphans to the root of the
hierarchy. In case of most OS processes, orphans are taken over by the
grandparent.

Considering the John's process hierarchy example again:

+ -> A -> B -> C
... B terminates

+ -> A -> B (zombie) -> C
... B gets deleted/reused (forbidden as of your proposal)

1) Situation in OSCI PoC implementation (moved to top-level):
  + -> A
   \-> C

2) Alternative (keep as direct child of grandparent):
  + -> A -> C

  Now, a user can still kill the whole hierarchy via a recursive
A.kill(...). And we don't have to specify complex rules when process
objects may be deleted, leaving more room for optimisations. Am I missing
something?

  It seems, that changing the OSCI implementation to keep the process
objects valid while there are living descendants is merely a two line
patch, though.

What do you think?

Greetings from Oldenburg,
Philipp

On 25/05/10 11:21, Bishnupriya Bhattacharya wrote:
> John,
>
> I agree with you that your proposed change to the LRM makes the process
control contructs more user-friendly.
>
> Note that in the Cadence implementation of what happens when a process
terminates, we made an early decision to make things work as in your
proposal. In our experience, keeping a terminated process around as long
as it has any live descendants benefits usability in several ways, one of
them being the include_decendants flag in the process control extensions.
>
> However, AFAIK, the OSCI implementation does not maintain this property
- that a process object is kept around (not deleted) as long as it has
live descendants.
>
> In summary, I cast my vote for your proposal. We probably need to hear
> from OSCI (Andy?)
>
> Thanks,
> -Bishnupriya
>
> ________________________________
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Tuesday, May 25, 2010 1:47 PM
> To: Bishnupriya Bhattacharya
> Cc: Neeti Bhatnagar; systemc-p1666-technical@eda.org
> Subject: 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
>
>
>

--
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
R&D Division Transportation | FuE-Bereich Verkehr Escherweg 2 * 26121 
Oldenburg * Germany
Phone/Fax: +49-441-9722-420/282 * PGP: 0x9161A5C0 * http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.