Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Randy Misustin (ram@Model.com)
Date: Wed May 21 2003 - 14:02:00 PDT
Hi Steve,
Thanks for thoughtful response. Discussion is below.
Steven Sharp wrote:
>>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.
>
>
What do you mean by "well defined"? I couldn't find anything that
directly addressed the topic of the effect of a fork on automatic
variables defined in an enclosing scope. Perhaps you know of a place
this is addressed? Or perhaps you're inferring that a lack of discussion
of this topic is tantamount to defining that this behavior should be the
same as with static variables?
>>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.
>
Absolutely.
>A subprocess created inside the scope will not.
>
Why not? (Oops, never mind. I guess that's what we're debating ;^).
>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.
>
Which part? The part where I say creates a new thread or the part where
I say a new stack? In either case, I presume you're arguing semantics.
I'm not discriminating between the terms thread, process, or subprocess.
As for stack I'm talking about whatever data structure you use to hold
execution context such as return address.
>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.
>
Clearly. I'm not arguing definition here.
>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).
>
>
Quite right.
>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.
>
>
Go Steve! I presume you mean "join_none" in the above (I misspoke the
same thing in my original post, so this is undoubtably my fault).
Reconciling the semantics of automatic variables with fork-join_none's
and then reconciling the semantics of the various flavors of fork with
each other is how I got to my current state of confusion.
Additionally, I seem to have this strong desire to define automatic
tasks and functions in terms of a traditional execution stack model.
This is a proven high-performance path to achieving reentrancy. The
largest obstacle (that I've so far considered) to this is this fork-join
strangeness. I'd hate for a lack of thoughful consideration of the
ramifications of this to be the blocking issue to a nice implementation.
Of course, this desire in me is probably curable.
I can't tell where your last paragraph is leading. Are you suggesting,
similar to Dave Rich, that fork-join_none ought to treat outer-scoped
automatic variables differently than other forms of fork or are you
starting to argue for the removal of fork-join_none?
Thanks once more for the discussion.
-randy.
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 14:29:01 PDT