RE: [sv-ec] disable class method

I agree with Steve:

- Disabling a method ought to disable all invocations of the task.

- Disabling a virtual method should be illegal.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Steven Sharp
Sent: Wednesday, July 18, 2007 11:35 AM
To: sv-ec@eda.org; danielm@aldec.com.pl
Subject: Re: [sv-ec] disable class method


>From: "danielm" <danielm@aldec.com.pl>

>I cannot found  in LRM  statements describing if "disable" is allowed
on
>class method (task) and how it should work.
> 
>I assume that if LRM doesn't forbid such usage so this is allowed, but
I
>still have doubts how it should work.

It is a task, so I agree that it would be allowed.  However, as with
other re-entrant tasks, it isn't very useful.  This is because of your
next question.


>1)
>Generally there are 2 possibilities. Disable can work per object(*) or
per
>class(**).

As specified in the LRM, it will disable all invocations of the task.
There is nothing special specified for class methods that changes this,
and passing a different 'this' argument does not make it a different
task.
Regardless of the object used to reference it, they are all calling the
same task.  I would expect the task name in a disable to be a static
reference, so you wouldn't even need to specify an object in the
disable.

I would expect the tasks in different specializations of a class to be
considered different tasks.  Since any static storage that they used
would
be distinct, I would expect them to be distinct for this purpose also.
This matches other tasks, where different instantiations of the same
task,
which therefore use different static storage, are distinct for
disabling.
The disabling mechanism was essentially static, and was left static when
automatic tasks were added to the language.


>2)
>Another question is what should happen if we try to disable method of
an
>non-existing object (below sample) - should it be runtime error(imho in
case
>we aprove disabling per object the it shoudl be runtime) or task called
in
>fork should be disabled in time 20 (this how it may work if we aprove
>disabling per class)?

If it would be legal to reference a static property this way, then it
should be legal to disable this way.  It is a static reference.  I would
also assume that you could reference without an object, with something
like "disable C::t", even for a task that is not a static method.


>3) 
>The simplest possibility is to try disable static task - because it can
be
>done with :: operator. There is no problem with null references, and
this
>obviously works per class. So maybe disabling should be allowed only
for
>static methods? and should disable all task being  currently in
progress

It would be best not to call it a "static task" if you mean "static
method".
A static task has static storage, and could be a static or non-static
member
of a class, or outside a class.  Conversely, a static method can be a
static
or automatic task.

Anyway, I agree that static methods are the simplest case, and I agree
with your description of how this would work.

As I mentioned above, if disabling non-static methods is allowed, I
would
expect it to work the same way as static methods.  Since disabling does
not require any access to any non-static members of the class, there is
no need for an object.  If this seems too confusing, your suggestion of
disallowing it for non-static methods may be a good idea.

Upon further thought, there is one situation where an object might get
involved, and that would be virtual methods.  The actual type of the
object might determine which implementation of the task would get
disabled
(i.e. the task declared in which base class).  This is so strange that I
would support making it illegal.


Steven Sharp
sharp@cadence.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.