RE: [sv-bc] RE: Can a function contain a fork/join/any/none?

From: Rich, Dave <Dave_Rich_at_.....>
Date: Tue Mar 21 2006 - 22:50:24 PST
I was trying to say that the rest of language is defined assuming that a
function has no user defined interactions with the scheduling of events.


The indirect side effect of a function writing to an externally visible
register is the only hole in this interpretation that is explicitly
allowed in the current LRM that I am aware of. BTW, this hole creates
additional holes by allowing program blocks threads to call functions
that make blocking writes to non-program block variables.

Final blocks are defined in terms of what was supposed to be legal in a
function. What happens if there if a fork/join_none inside a final
block? Do we make that illegal or just ignore the thread(s) created?

Program blocks are supposed to implicitly exit after all threads created
by initial block. That works because only initial blocks can start a
thread.

I don't think anyone can argue that the current LRM allows functions to
call a task or contain blocking statements. The argument about whether
fork/join**** is legal is moot without those constructs inside the
function.

This may very well be a desirable enhancement request, but it's much
more complex than just removing a few restrictions in the definition of
functions.

Dave



> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven
> Sharp
> Sent: Tuesday, March 21, 2006 5:45 PM
> To: sv-bc@eda.org; sv-ec@eda.org; shalom.bresticker@intel.com
> Subject: RE: [sv-bc] RE: Can a function contain a fork/join/any/none?
> 
> 
> >From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> 
> >> Is it really true that "functions are not supposed to interact
> >> with the scheduler"?
> 
> I don't believe that there is anything in the LRM that says this.
> Dave Rich was stating his interpretation, which is stronger than
> what the LRM actually says.
> 
> 
> >> This implies that the scheduler may suspend function execution
> >> in the middle. If this is not so, it needs to be explicitly
> >> stated.
> 
> Based on the LRM, there is nothing preventing the scheduler from
> suspending function execution in the middle.  There are situations
> where an implementation might want to do this.  If the implementation
> wants to inline a continuous assignment from a variable to a net any
> place the variable is written, and the variable is written in a
> function, then the continuous assignment would be inlined there.  This
> is equivalent to doing the assignment to the variable, suspending the
> function in favor of the continuous assignment, and then resuming the
> function afterwards.
> 
> An implementation could get itself into trouble if it went too far
> in suspending function execution.  If a continuous assignment called
> a function, the function suspended, other processes updated inputs of
> the continuous assignment that it had already read, and then the
> function resumed, the continuous assignment might not work properly.
> It evaluated with the old values, and might not re-evaluate for the
> changes since it was suspended when they were happening.
> 
> Steven Sharp
> sharp@cadence.com
Received on Tue Mar 21 22:50:32 2006

This archive was generated by hypermail 2.1.8 : Tue Mar 21 2006 - 22:50:50 PST