RE: [sv-ec] RE: [sv-bc] Can a function contain a fork/join/any/none?

Gord,

 

I agree with your suggestion that we should remove the statement
regarding when the threads spawned with a fork/join_none start
executing. It should be sufficient to state that the parent thread
executes concurrently with the spawned threads, and therefore a function
that creates threads using fork/join_none is non-blocking.

 

As Steven Sharp pointed out, the rewrite is not exactly the same because
the parent/child relationship of the threads is different. And, the
parent/child ordering does impact how RMG states are seeded among other
things. Note that the LRM does not define when the seeding takes place,
only how the seeding proceeds when a thread must be seeded.

 

Clearly it will be impossible to replicate the thread parent/child
relationship with a rewrite that uses a static thread. I didn't mean for
the rewrite to be the way to implement this feature, only to use it as a
vehicle for explaining the semantics, as well as the difficulties that
users will face if the language doesn't support this feature. Evidently,
the implicit (auxiliary) thread would be illegal in a package, but that
needn't be the case for a fork./join_none within a constructor or other
function.

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Wednesday, February 22, 2006 2:15 PM
To: Arturo Salz
Cc: Rich, Dave; sv-ec@eda.org; sv-bc@eda.org
Subject: Re: [sv-ec] RE: [sv-bc] Can a function contain a
fork/join/any/none?

 

 

 

Arturo Salz wrote:

[...]

> 

> [Arturo] I agree with this statement. As a starting point we could 

> define this in terms of the following legal transformation:

 

 

Arturo, I think that we could go this way but note that your rewrite

is not quite the same semantically.

 

In particular, if I have:

 

    C my_c = new();

 

the rewritten routine makes no guarantees about when the "always"

block containing the fork...join_none will run with respect to

any other initialization.  This could be somewhat surprising if

a user expects the threads to get started (an perhaps do some

initialization for the thread states) before other initial blocks run.

 

If we go this route (or similar), I'd really like to see the current

LRM wording changed such that this is a valid rewrite for both

function and non-function fork...join_none (thus loosening the

current restriction that fork...join_none can't be started until

a blocking stmt is encountered).

 

Further, would this also impact the RNG states?  Dave brought that

up and the issue of how one counts this is important.

 

This may also be a bit of a semantic issue in terms of how

to seed such implicit threads that might exist in a package.

 

Gord.

 

 

>             class C;                        =>        class C;

>                 function C::new();                      static 

> mailbox#(C) mbox = new();

>                     ...

>                     fork XXX join_none               function
C::new();

>                     ...
...

>                 endfunction
mbox.put( 

> this );

>             endclass                                           ...

>
endfunction

> 

>                                                                 task 

> fork_in_new()

>
fork 

> XXX join_none;

>
endtask

> 

>                                                             endclass

>                                                             always
begin

>                                                                 C q;

>     C::mbox.get( q );

>     q.fork_in_new();

> end

> 

>  

> 

> It's important to note is that although the two code versions are 

> semantically equivalent, the right one is a lot more verbose and error


> prone.

> 

> Dave

> 

>  

 

-- 

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

Gordon Vreugdenhil                                503-685-0808

Model Technology (Mentor Graphics)                gordonv@model.com