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

Steven,

 

My comments inlined below.

 

            Arturo

 

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Wednesday, February 22, 2006 3:22 PM
To: Dave_Rich@mentor.com; Arturo.Salz@synopsys.COM; sv-ec@eda.org;
sv-bc@eda.org
Subject: RE: [sv-ec] RE: [sv-bc] Can a function contain a
fork/join/any/none?

 

 

>[Dave] But now we have to attach scheduling semantics to functions,
consider

>how disable, fine grain process control, and randomization interact
with

>the thread hierarchy.

> 

>[Arturo] I don't believe this is true. If we treat fork/join_none is

>just one more of the many side effects already allowed by functions
then

>there is nothing special about a function that creates threads as a
side

>effect.

 

Those other side effects do not create a parent/child relationship

between the function thread and the pre-existing thread it is waking

up.  The issues that Dave is raising all have to do with the extra

semantics attached to that relationship.

 

[Arturo] Yes, but that parent/child relationship is not new to the 

language: tasks exhibit the exact same issues, and implementations

must be able to deal with these same issues with respect to tasks.

 

>[Arturo] Incidentally, all the issues you bring up must be well defined

>for tasks; I don't believe they represent anything particular for

>functions.

 

Functions can appear in contexts where you cannot have a task.  Some

of these have been mentioned: variable declaration initializations and

continuous assignments.  So even if the issues are fine for tasks, that

does not necessarily mean they are fine for functions.

 

[Arturo] Yes, this is true. However I don't know that these represent

a problem. If there are any issues, I'd like to discuss them.

BTW, it may not be a good idea to call a function that spawns new 

threads via a continuous assignment.

 

>What problem do you foresee if an exported function creates threads? As

>I stated earlier, a function can already spawn threads by modifying

>variables. Whether the function is called via DPI or not seems (to me
at

>least) largely irrelevant.

 

Modifying variables does not spawn a thread; it can only wake up an

existing thread that is currently blocked waiting on the variable.

Since I have encountered people who believe incorrectly that

"always @(event)" spawns new processes, perhaps you have this same

idea.  Or perhaps you just mean that the awakened thread can spawn

new threads.  But in that case, those threads are children of the

awakened thread, and have no hierarchical relationship to the

thread in the function.

 

[Arturo] I wasn't specific in this message: I meant that the awakened 

thread can spawn new threads.

Nonetheless, you are correct when you point out that the parent/child 

relationship of the threads in the two situations is not the same. But, 

does this particular parent/child thread relationship represent a
problem? 

I don't believe it's a problem. In fact, it may be a benefit: it allows
users 

to create a different (presumably the proper) parent/child relationship.

 

I don't know if there are serious issues here, but the comparisons

with tasks and with waking up other processes by writing to variables

are not similar enough to prove there are not.

 

[Arturo] I didn't claim that these were identical. Clearly, they are
not.

My point is that all of these issues exist in other contexts and the 

tools must be able to deal with them. By extension, these do not

represent any fundamental or implementation problem.

 

Steven Sharp

sharp@cadence.com