Subject: Re: [sv-ec] fork..join_none/join_any and automatic variables
From: Steven Sharp (sharp@cadence.com)
Date: Wed May 21 2003 - 11:02:42 PDT
>I agree with Mac 100% for join and join_any,but not for join_none, the
>case where the spawned thread might out-live the normal lifetime of the
>automatic variables it may reference.
The IEEE 1364-2001 solution to this was to disallow references to the
automatic variables in subprocesses that could out-live the lifetime
of the variable.
>Another problem is passing unique values to multiple spawned threads.
>Suppose I wanted to write this
>
>for(int i = 0;i<N;i++)
> fork
> do_this(i);
> do_that(i);
> join_none
>
>Unless I put a non-zero delay in the loop, all of the tasks will pass
>the final value of i as its argument, not 0,1,2,3....
Unless there are some additional constraints on execution order in SV,
"will pass" should be "could pass". It wouldn't even be guaranteed to
produce this undesirable result. I think that a #0 in the loop after
the join_none would force the subprocesses (as "active events") to
execute before the #0 (which goes on the "inactive queue"), but that
stuff in Section 5 of IEEE 1364 has always been vague and questionable.
>By creating a copy of the automatic variables for each thread, both
>problems are eliminated.
It would be inconsistent with the specified semantics of automatic
variables. Nor would it solve the problem. Note that when an automatic
variable is allocated it is initialized to the default initialization
value, which is x in this case. You are not only assuming a new allocation
of a variable that was already allocated, but that the new variable will be
initialized to the value that the existing variable currently has. You
may not be consciously aware that you are making up these new rules, but
there is certainly nothing in the specification about them.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed May 21 2003 - 11:37:12 PDT