RE: Children of dead processes

Bishnupriya, Philipp,

I now have:

get_parent_object ..... If the parent object is a process instance and
that process has terminated, get_parent_object shall return a pointer to
that process instance. A process instance shall not be deleted (nor any
associated process handles invalidated) while the process has surviving
children, but may be deleted once all its child objects have been deleted.

terminated..... When the underlying process instance terminates, if the
process instance has no surviving children an implementation may choose to
invalidate any associated process handles, but is not obliged to do so. An
implementation shall not invalidate a process handle while the process
instance has child objects.

I hope this issue is now closed?

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann"
<philipp.hartmann@offis.de>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
13/01/2011 13:00
Subject:
RE: Children of dead processes

John, Philipp,
 
Yes this works quite well.
 
I feel it will be good to explicitly call this out in the LRM ? that if a
terminated process object has live children, an implementation is
obligated to keep both the process object alive (by the new rule we
coined) and hence any associated process handles alive (by inference from
what John quotes below).
 
Thanks,
-Bishnupriya
 
 
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, January 13, 2011 2:36 PM
To: Philipp A. Hartmann
Cc: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
Subject: Re: Children of dead processes
 
Philipp, Bishnupriya,

Yes, I think we are on the same page.

Currently, the LRM says (under bool terminated() const) : "When the
underlying process instance terminates, an implementation may choose to
invalidate any associated process handles but is not obliged to do so."

The LRM also says "However, if an implementation chooses to invalidate a
process handle, it shall invalidate every process handle associated with
the underlying process instance at that time. In other words, it shall not
be possible to have a valid and an invalid handle to the same underlying
process instance in existence at the same time."

So given the existence of
explicit sc_process_handle( sc_object* );

we could choose to infer that in the case where a process object continues
to exist only because it has surviving children, then the implementation
is obliged to keep any process handles valid, even after the process
instance has terminated.

Does that work?

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
Bishnupriya Bhattacharya <bpriya@cadence.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
12/01/2011 17:25
Subject:
Re: Children of dead processes
 

John,

is there any reason to invalidate a process handle, if the underlying
process object continues to exist (and logically points to the same
instance, i.e. is not yet re-used)?

 I would even prefer to allow the deletion of such parent objects over
having this mismatch between child.get_parent_object() and invalidated
handles.

 From an implementation POV, one could still create new handles via
sc_process_handle( child.get_parent_object() ), right? We would then
have to make it implementation-defined, if handles of terminated
processes can be created.

Greetings from Oldenburg,
 Philipp

On 12/01/11 17:54, john.aynsley@doulos.com wrote:
>
> Indeed. An implementation may choose to invalidate any process handles
as
> soon as a process instance terminates. In the case of a terminated
process
> with children, we have to decide whether the implementation is obliged
to
> keep any process handles valid as long as the process object continues
to
> exists. Otherwise we may have the situation where there exists a
> non-terminated child process whose parent process continues to exist but

> has an invalid handle. I do not see this is a problem, but it does seem
a
> little odd.
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> Bishnupriya Bhattacharya <bpriya@cadence.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 12/01/2011 14:53
> Subject:
> Re: Children of dead processes
>
>
>
> Yes, exactly.
>
> Additionally, this has implications for the invalidation of process
> handles as well, right?
>
> Philipp
>
> On 12/01/11 13:49, john.aynsley@doulos.com wrote:
>> Bishnupriya, Philipp,
>>
>> Agreed. So as I understand it, we are proposing that for every
> occurrence
>> of get_parent_object() in the LRM, we change the description to say
that
>
>> the following:
>>
>> If the parent object is a process instance and that process has
>> terminated, get_parent_object shall return a pointer to the process
>> instance. The parent process instance shall not be deleted while the
>> process instance has child objects, but may be deleted once all its
> child
>> objects have been deleted
>>
>> Right?
>>
>> John A
>>
>>
>>
>> From:
>> Bishnupriya Bhattacharya <bpriya@cadence.com>
>> To:
>> "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
>> "philipp.hartmann@offis.de" <philipp.hartmann@offis.de>,
>> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
>> Date:
>> 11/01/2011 18:14
>> Subject:
>> RE: Children of dead processes
>>
>>
>>
>> John,
>>
>> Philip raises excellent questions, and I?m very much in favor of
> mandating
>> that parent process objects with live children should not be deleted.
It
>
>> provides a nice, clean, intuitive semantics with no ?surprises? for the

>> user.
>>
>> Thanks,
>> -Bishnupriya
>>
>> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
>> Sent: Tuesday, January 11, 2011 6:04 PM
>> To: Bishnupriya Bhattacharya; philipp.hartmann@offis.de;
>> systemc-p1666-technical@eda.org
>> Subject: Children of dead processes
>>
>> All,
>>
>> Philipp has raised the following issues:
>>
>>
>> 6.6.5 sc_process_handle::get_parent_object
>> 6.16.7 sc_object::get_parent_object
>>
>> "If the parent object is a process instance and that process has
>> terminated, get_parent_object shall return either a pointer to the
>> surviving process instance or a null pointer if it has been deleted."
>>
>> What happens to the object's position itself, when the parent object
is
>
>> NULL?
>>
>> - It can still be found via sc_find_object( obj.name() )?
>>
>> - Is it moved to the top-level, i.e. can it be found via
>> sc_get_top_level_objects()?
>>
>> - But then basename() != name(), but (since no parent)
>> get_parent_object()->name() '.' basename() != name()
>> (The name can't be changed, since it is meant to stay valid until
> the
>> object is deleted?)
>>
>> This may affect sc_event naming as well.
>>
>>
>> 6.16.1 sc_object Description (see get_parent_object above)
>>
>> "... objects of a class derived from sc_object may be deleted at any
>> time. When such an sc_object is deleted, it ceases to be a child."
>>
>> If it has child objects itself (in case of a process), what happens
to
>
>> their position in the hierarchy? And their names?
>>
>> I would even prefer to have a restriction that in case, the "parent"
>> object shall not be deleted/invalidated until all children have been
>> deleted. But this might break "early invalidating" implementations.
>>
>>
>> [JA] We have already agreed that dynamic processes may be terminated
> while
>> they still have children, in which case a call to get_parent_object()
> for
>> any orphaned objects returns a null pointer. On the other hand,
> insisting
>> that parent process objects cannot be deleted while they have surviving

>> children would be a clean solution.
>>
>> Opinions?
>>
>> John A
>>
>>
>>
>>
>
>

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