RE: [sv-ec] How does static lifetime interact with virtual methods?

Gord,

I don't understand your confusion.

In your example there are two tasks (C::t and D::t). Each task has an
"x" argument with static lifetime. Hence:
 1) There are two "x" arguments: C::t.x and D::t.x.
 2) C::t.x is the same for all invocations of C::t(likewise for D::t).
 3) Simultaneous calls to C::t will indeed interfere with the value of
"x".
 4) Calls to C::t and D::t do not interfere with the value of "x".

As for "this" I do believe that it ought to always be automatic. This
should be clarified in the LRM, although we can infer that it must be
the case from the verbiage of the current LRM:
	The this keyword denotes a predefined object handle that refers
to the 	object that was used to invoke the subroutine that this is used
within.
If "this" is not automatic - hence, different invocations can interfere
with the value of "this" - the above statement would be false.

Whether having arguments with static lifetime in a virtual function is a
sensible thing or not, I don't believe it is sensible - or perhaps even
useful - but I don't think it's worth writing special rules in the LRM
tackle this. BTW, a virtual method with no arguments and static lifetime
is indeed sensible. 

Therefore, in order to deal with the not-so-useful situation we would
have to write more special case rules: "disallow virtual methods with
static lifetime only when the method has no arguments, etc...".

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Thursday, June 14, 2007 10:15 AM
To: SV_EC List
Subject: [sv-ec] How does static lifetime interact with virtual methods?


If one has:
      class C;
          virtual task static t(int x); endtask
      endclass

      class D extends C;
          task static t(int x); endtask
      endclass

How should one think about "this" and "x" in terms of the two
bodies of "t"?  Is "this" implicitly automatic?  Is there
one "x" or two?  Should simultaneous calls to "t" in C
be able to interfere with the value of "x" in the "t" in D?

More to the point -- is this even a sensible thing to permit
in the LRM?  It seems to me that from first principles, the
concept of "virtual" and "static lifetime" are at least
somewhat contradictory.  We could clarify the rules, but
is it really worthwhile?

I'd be happy to make it illegal to have static lifetime for a
virtual method.

It is also arguable (though less strange) that "static lifetime"
should really only be permitted for class static routines.  You
do run into some oddness with "this" if that isn't the case --
i.e. is "this" really a static lifetime implicit formal or is it
automatic and the rest static?

I'd be happy to restrict static lifetime to static methods as
well.

I'll enter a mantis item on this and will add a proposal if people
are in favor of one or both of the restrictions.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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


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