Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Steven Sharp (sharp@cadence.com)
Date: Wed May 21 2003 - 10:41:46 PDT
> From my user-sanity perspective, I tend to agree, although I'm
>unconvinced that this is a compatibility issue (unless, of course,
>you're thinking about the implications on 1364-2001 automatice tasks,
>but this whole discussion is relevant to it as well).
This is relevant to fork-join used inside an automatic task or function
in 1364-2001. That behavior is well defined. If SV comes up with a
different answer, then it is incompatible.
>Ahh, this last statement is the core issue. As you said, multiple
>simultaneous executions need to have their own copy of i. I guess given
>your ealier reaction and thinking, you feel that the code executing
>within the fork isn't a separate simultaneous execution?
Each process entering the scope from outside will get a new copy of all
of the variables, initialized to their default initialization value.
A subprocess created inside the scope will not. If it helps, think of
executing the "begin" as creating the variables. You can think of
executing the "end" as deallocating them, but this isn't quite as simple
since a break, continue, return or disable could also exit the block and
deallocate the variables.
>A fork statement creates a new thread and, with it, a new stack. This
>argues heavily that all forms of forks copy relevant stack areas at
>fork-time.
As an implementor, I can tell you that this is incorrect. So are your
resulting conclusions. A fork statement has specific semantics that
are not defined in terms of creating stacks or new copies of variables.
The subprocesses in the fork all operate in the environment where the
fork appears, including access to the same variables. (Though a
fork can be named, creating a new scope that all of the subprocesses
are inside, but that is effectively equivalent to putting a begin-end
with the same name around an unnamed fork).
The new types of nonblocking forks would fall under the description in
10.2.3 of 1364-2001 that says "Because variables declared in automatic
tasks are deallocated at the end of the task invocation, they shall not
be used in certain constructs that might refer to them after that point."
Since a subprocess of such a fork might refer to the variable after it
had been deallocated, such a subprocess would not be allowed to reference
the automatic variable. Of course these forks are not listed in the
specific examples in 1364-2001 since they are not part of the language,
but they are in the same category as those examples.
These forks do create a new wrinkle. The subprocesses in 1364-2001
cannot themselves introduce new scopes and automatic variables, while
the new fork types can. A subprocess of a fork-join_any could contain
a begin-end block that declares some automatic variables. There is no
reason why this would not be legal and why the subprocess could not
refer to these variables. The subprocess cannot out-survive the variables
in this situation. The restriction would become more complex: instead of
not being allowed to refer to any automatic variables, the subprocesses
would not be allowed to refer to any automatic variable in a scope outside
the subprocess. Note that such automatic variables declared inside of a
fork-join_any subprocess would be allocated each time execution entered
their scope, so that if the subprocess were executed multiple times
concurrently, each subprocess would have its own copies.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 10:54:12 PDT