Re: [sv-ec] Scheduling cycle

Arturo (and Steven),

If you want to preserve the benefits of the separation in scheduling 
semantics that have been so forcefully argued of recent, then the 
situation illustrated in the example in 17.5 has to be revisited. This 
example illustrates a module variable, a, being updated in the Reactive 
region. Isn't the whole point of this morning's discussion to ensure 
that module variables are updated in a non-Reactive region?

I guess one could try to define a set of rules that would allow a task 
or function in a module to be called without a synchronization, but as 
you say, such a determination isn't an easy thing to analyze statically. 
Steven brought up the issue of the task-writer's intent, but seemingly, 
if the task or function was written assuming module-scheduling rules, 
then it's a tough thing to reason about intent when called from a 
program (at least if the task/function has any side-effects [including 
the update of non-automatic local variables]).

To be fair, Steven quite astutely limited his objection to "pure" 
functions in packages. I had thought that the reasoning behind the 
strange anonymous program construct in packages was to provide program 
scheduling semantics to tasks and functions. If the intention were to 
write a function or task that exhibited non-delay behavior when called 
from a program, it should be placed in an anonymous program, no?

-randy.

Arturo Salz wrote:

>I agree with Steve.
>
>It's also not generally feasible to determine statically whether a 
>conditionally blocking task is a simple zero-delay task or not.
>And, in the case of static tasks, this also opens up the issue of 
>when should the arguments be copied into the task.
>
>    Arturo
>
>----- Original Message ----- 
>From: "Steven Sharp" <sharp@cadence.com>
>To: <sv-ec@eda.org>; <gordonv@Model.com>
>Sent: Thursday, April 28, 2005 3:32 PM
>Subject: Re: [sv-ec] Scheduling cycle
>
>
>Gord wrote:
>  
>
>>  2) a call to a non-program function or task should delay
>>     the thread to the Reactive NBA region before AND after
>>     the enable
>>    
>>
>
>But this means that a call to a 'pure' function or simple zero-delay
>task defined in a package would result in blocking the thread.  This
>is probably not what was intended when the subroutine was written to
>have no delays.
>
>Steven Sharp
>sharp@cadence.com
>
>
>
>  
>