Subject: Re: [sv-ec] Comments on Chapter 9
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Jan 24 2003 - 14:35:16 PST
I think Kevin has done some really useful brainstorming related
to processes and fork/join.
1) fork/join
Aside from the benefit of avoiding the use of common
words any, all, and none, Kevin's suggestions made me
think of a more natural syntax:
grp1: fork
p1();
p2();
p3();
join(expression)
Borrowing from the definition of repeat:
"statement unblocks when a fixed number of threads
have completed. If the expression evaluates to unknown or
high impedance,it shall be treated as zero,and fork/join
shall immediately unblock"
I'll let the language lawyers decide if we really need
a ';' at the end of join(expression)
I don't know that I want to define anything for negative values.
I'm inclined to treat them the same as zero.
Defined in this way, I could actually see where I would be able
to take advantage of having a variable number of threads return
immediately. For example, I could easily decide whether an operation
should be performed in the background by passing a parameter to
a task.
2) process
In general, I'm in favor of eliminating needless keywords, but I
have to say that process is much more clear that I am creating
a new process than fork/join none or fork/join(0). I won't cry
bitterly if it is thrown out, but for creating a dynamic background
process, I still like it.
3) process methods
Kevin recently introduced the idea of using methods with fork/join:
At 11:04 AM 1/13/2003 -0800, Kevin Cameron x3251 wrote:
> function process spawn_func()
> begin
> f1: fork p1();
> p2();
> p3();
> join 0;
>
> spawn_func = f1.process_id(); // return process group id
> end
> endfunction
I like the idea of better control over what get's terminated
than the simple $terminate. Time after time when working in
Vera, I had code like:
initial begin
...
process self_terminating_background_task();
fork
stat = setup();
do_check();
join(1) // or "join any" if you must...
if (stat == FAILED)
$terminate;
end
What I really wanted, was to kill just the children related
to the fork/join, not the process above it. Sure I worked
around the problem, but I would much rather see this solved.
Two solutions:
3a) disable
I'd be happy if we defined "disable" to kill children of the
named block, task, etc. All I would need is a label on the
fork or the process (if we decide to keep it) and we could
use disable. I'm not really fond of $terminate, but I suppose
it wouldn't hurt to have in addition to adding clarity on
what disable does when there are child processes.
3b) process_id() method
This seems like a good idea. The biggest issue is what can I
give it to. Although the other suggested methods of suspend()
and restart() were given, it would seem that we would rather
get a process id and then have a collection of tasks that
could do something with it.
4) $wait_child
I would rather have a $wait_pid(pid) task than $wait_child
since there may only be some of the children I want to wait
for. This has certainly been the case for my experience when
working with Vera environments. If we don't do this, I'll
be forced to use my Vera kludges again: make a task that
calls only the children I want to wait for. That way, my other
children won't clog my wait... since I can't select
individual children in a $wait_child
Stefen
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Fri Jan 24 2003 - 14:39:23 PST