Subject: Re: Questions re fork/join
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Aug 01 2003 - 08:08:54 PDT
As Peter said there are many problems associated with forked processes
accessing outer scope automatic variables. One forked process could access
a variable that has been deallocated (case where the forks occur from
within a sequential procedure call and the fork out-lives the procedure
life time) or would the fork create copies of all variables and access its
own copies?
In the proposal there is no finer grain of control of the forked processes
such as kill the forked processes once a condition has been reached.
Finally, I would also ask examples of uses of the fork/join which
illustrate the modelling advantages that this will bring to VHDL.
Francoise
'
At 09:40 PM 8/1/2003 +0930, Peter Ashenden wrote:
>Folks,
>
>I've just been looking over the proposal for fork/join (TBV3) and have a
>number of questions and comments. Some of them are related to the
>underlying langauge abstractions, so I'm putting my DTA hat on here.
>
>(1) What is the driving requirement? What modeling task is made difficult
>with the language as it stands, that would be facilitated by a fork/join
>construct?
>
>(2) Has consideration been given to whether other extensions or revisions to
>VHDL's concurrency model would meet the requirement?
>
>(3) Assuming the fork/join as proposed, what are the semantics of accessing
>variables whose scope extends to a fork/join statement? Given that such a
>variable is visible in multiple threads of execution, should that variable
>be a shared variable of a protected type? If not, then we've bought back
>into the whole question of concurrency control from VHDL-93.
>
>(4) What is the rationale for the various forms of join? Why not just
>proceed when all forked threads have completed? (There is precedent for
>this in other languages, namely, CSP and its derivatives.)
>
>(5) The comment in the proposal about lifetimes of objects compared with
>lifetimes of threads is a significant one. Currently, all objects lifetimes
>are limited to the lifetime of the enclosing block, process or subprogram.
>The comment author suggests resolving the lifetime issue by terminating all
>forked threads when the forking subprogram ends. There are significant
>problems with that. For example, a forked thread could be accessing a
>variable in an outer scope when terminated due to completion of the forking
>procedure. That could leave the variable in an inconsistent state. It
>would be safer to make a procedure suspend until all forked threads had
>completed. it would be simpler still only to allow "join all".
>
>Looking forward to comments on these thoughts.
>
>Cheers,
>
>PA
>--
>Dr. Peter J. Ashenden peter@ashenden.com.au
>Ashenden Designs Pty. Ltd. www.ashenden.com.au
>PO Box 640 Ph: +61 8 8339 7532
>Stirling, SA 5152 Fax: +61 8 8339 2616
>Australia Mobile: +61 414 70 9106
This archive was generated by hypermail 2b28 : Fri Aug 01 2003 - 08:09:38 PDT