[sv-ec] Action item 11


Subject: [sv-ec] Action item 11
From: Neil Korpusik (Neil.Korpusik@Sun.com)
Date: Mon Sep 22 2003 - 17:56:27 PDT


Here is my write-up for action item 11.

Neil

--------------------------------------

Disposition of automatic variables in the presence of:

    fork/join_none
    fork/join_any

SV 3.1 added the fork/join_none and fork/join_any constructs.

It has since been discovered that there is a hole in the SV 3.1 specification
with regards to automatic variables that are used by sub-processes spawned by
fork/join_none and fork/join_any. These automatic variables may cease to exist
while sub-processes that use them continue to exist.

Various proposals and ideas for dealing with this issue have been circulated
on the reflector and discussed in the SVEC bi-weekly meetings. This email
contains a summary of the various issues and a set of options for dealing with
each of them. A list of pros and cons is given for each proposed option.

At the next SVEC meeting 29 September 2003 we will be voting on these various
options.

-------------

Example of the problem:

   This example has since been referred to as the "looping problem".

   The statements spawned by join_none can potentially outlive the return of
   the containing task. It doesn't matter whether the fork/join_none is
   contained within a task that is automatic or static, or even inside a task
   at all. It's the automatic looping variable j that can cause problems.

      initial
      for(int j=1; j<=3; ++j)
           fork
               #1 $display( "j=%0d", j);
           join_none

   The values of j used within the calls to $display could be undefined since
   the automatic variable j may go out of scope before any of the sub-processes
   have had a chance to start.

   In this example the intended behavior would be for each $display to
   receive a different value of j (e.g. 1,2,3).

-------------
There are 3 main points to consider in this situation.

  - Sharing of automatic variables

    Should sub-processes spawned by fork/join_any and fork/join_none be
    allowed to share automatic variables that are contained within the scope
    which spawns those sub-processes?
 
  - Lifetime of automatic variables
 
    When should the automatic variables within the containing scope be
    allowed to cease to exist?
 
  - Local copies of automatic variables
 
    Should local copies of automatic variables be passed to sub-processes
    spawned by fork/join_none and fork/join_any?
 
-------------
 
Example of user-specified local copies of automatic variables
 
   The following example shows how a set of automatic variables could be
   specified to be passed to sub-processes.
 
   fork (a, b, c, d) // user specified list of automatic variables
      begin
        ...
      end
   join_none
 
-------------
Voting:
 
Instead of voting on the individual points and thus potentially ending up
with an inconsistent set of rules it would be preferable to vote for one
of the following 7 scenarios. Let us know if there are any other scenarios
that should be considered.
 
It appears that there will be some sort of inconsistency with V2K no matter
which scenario is chosen.
 
Scenarios:
            
   1 1.a
   2 1.b
   3 1.c
 
   4 2.a.1
   5 2.a.2
 
   6 2.b.1
   7 2.b.2
 
1. Sharing of automatic variables is disallowed for join_none and join_any
 
   + avoids race conditions
   + automatic variables can't prematurely go out of scope
   - inconsistent with V2K fork/join access to automatic variables
 
   a. A local copy of used automatic variables is made (for each sub-process)
     
      This is the original proposal made in ERR-4.
 
      + provides a simple solution to the "looping problem"
      - inconsistent with V2K automatic variables
 
   b. A local copy is made only for user-specified automatic variables
    
      + consistent with V2K automatic variables, adds a new semantic
        on top of what is already there
      + provides a simple solution to the "looping problem"
      - a bit more verbose
 
   c. No local copy support is provided.
 
      + consistent with V2K automatic variables, no new semantics
      - it would be very cumbersome to work around the "looping problem"
 
2. Sharing of automatic variables is allowed
 
   + consistent with V2K fork/join access to automatic variables
   - possible race conditions (consistent with V2K)
      
   a. The lifetimes of shared automatic variables depend on when sub-processes
      stop using them.
 
      + automatic variables can't prematurely go out of scope
      - inconsistent with V2K automatic variables
      - could be difficult to implement
      - could cause a hit in simulation performance
 
      1. Users have the option of specifying a set of automatic variables
         that are to be locally copied.
 
         This is the way Vera works today
 
         + provides a simple solution to the "looping problem"
 
      2. No local copy support is provided.
 
         - it would be very cumbersome to work around the "looping problem"
 
   b. The lifetimes of automatic variables end when they go out of scope
 
      + no changes to V2K automatic variables
      - automatic variables can prematurely go out of scope
 
      1. Users have the option of specifying a set of automatic variables
         that are to be locally copied.
 
         + provides a simple solution to the "looping problem"
         + allows automatic variables to be prevented from prematurely going
           out of scope
 
      2. No local copy support is provided.
 
         - it would be very cumbersome to work around the "looping problem"
 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems 
email: neil.korpusik@sun.com
---------------------------------------------------------------------



This archive was generated by hypermail 2b28 : Mon Sep 22 2003 - 17:57:54 PDT