Subject: [vhdl-200x-dta] FW: Questions re fork/join
From: Peter Ashenden (peter@ashenden.com.au)
Date: Fri Aug 01 2003 - 05:13:48 PDT
Folks,
I just posted the attached to the vhdl-200x-tbv list. I should also copied
it to DTA, but forgot before hitting Send.
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-----Original Message----- From: owner-vhdl-200x-tbv@eda.org [mailto:owner-vhdl-200x-tbv@eda.org] On Behalf Of Peter Ashenden Sent: Friday, 1 August 2003 21:41 To: vhdl-200x-tbv@eda.org Subject: Questions re fork/join
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 - 05:14:45 PDT