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.comReceived on Wed Feb 22 23:46:52 2006
This archive was generated by hypermail 2.1.8 : Wed Feb 22 2006 - 23:47:43 PST