Re: Process Control Extensions

Philipp, All,

Replies below:

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:
27/05/2010 01:03
Subject:
Re: Process Control Extensions

John, Bishnupriya,

  since there seems to be a strong preference to keep terminated process
objects in case of "living descendants", I had a closer look at the
current OSCI beta PoC implementation.

  I think, there are currently some things left unspecified in the LRM
regarding dynamically created processes/objects and the object
hierarchy, when after their lifetime has ended.

 1) What is a living descendant? Only spawned processes, or any class
    derived from sc_object (i.e. any non-empty child_objects vector)?
    If a parent of an object does not change during its lifetime,
    sc_objects are covered as well, right?

----------
[JA] This is a known problem with 1666-2005. I have already added the
following (marked in red). Of course, this is all up for discussion:

const std::vector<sc_object*>& get_child_objects() const;
Member function get_child_objects shall return a std::vector containing a
pointer to every instance
of class sc_object that is a child of the underlying process instance.
This shall include every
dynamic process instance that has been spawned during the execution of the
underlying process
instance and has not yet been deleted, and any other application-defined
objects derived from class
sc_object created during the execution of the underlying process instance
that have not yet been
deleted. Processes that are spawned from child processes are not included
(grandchildren, as it
were). If the process handle is invalid, member function get_child_objects
shall return an empty
std::vector.

bool terminated() const;
<snip>
When the underlying process instance terminates, an implementation may
choose to invalidate any
associated process handles but is not obliged to do so. 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. If the process handle is
valid, function terminated will return true, or if invalid, terminated
will return false. The process
instance shall continue to exist as long as the process handle is valid.
Once all the handles associated
with a given process instance have been invalidated, an implementation is
free to delete the process
instance, but is not obliged to do so. An invalid process handle may still
remain associated with a
process instance even after that process instance has been deleted.

virtual ~sc_object();
The destructor shall delete the object, shall delete any attribute
collection attached to the object, and
shall remove the object from the object hierarchy such that it is no
longer a child.

sc_object* get_parent_object() const;
Member function get_parent_object shall return a pointer to the sc_object
that is the parent of the
current object in the object hierarchy. If the current object is a
top-level object, member function
get_parent_object shall return the null pointer. 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.
----------

 2) Should it be guaranteed, that a dynamic sc_object is removed from
    the hierarchy, after its lifetime has ended?

----------
[JA] My thinking was that each dynamic process instance and each dynamic
sc_object has an independent lifetime, and there is a dependency between a
process handle and its underlying process instance. I have now tentatively
proposed that a parent process instance cannot be deleted while it has
living child processes. But should the same constraint apply between
parent process instances and child sc_objects (which are all part of the
object hierarchy)? I guess it should.
----------

 3) If a process has terminated (valid or not), and another process
    with the same name is created later on, what happens to its unique
    name in the hierarchy? What happens, if there aren't any living
    descendants? Should it be guaranteed to be removed from the
    hierarchy?

----------
[JA] Sounds like a good question 8=) Given what we've said about deleting
process instances, I guess the current answer is "implementation
dependent", but that does not seem very satisfying.
----------

<snip>

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