Subject: Re: [sv-ec] Proposals for EXT-2., EXT-9, and EXT-14
From: Kevin Cameron (sv-xx@grfx.com)
Date: Mon Aug 18 2003 - 09:29:06 PDT
On Mon, 18 Aug 2003, Arturo Salz wrote:
>
> The proposed approach does rely on a process passing its own id to any other
> process, including its parent process. The ability of a process to obtain its own
> process handle is required functionality.
It's only required because the parent can't get it. Unix lightweight and
regular process creation returns the thread id to the createing process
(in most cases the child doesn't need to know it's own id).
> To obtain a process before the process is executes (upon its creation) requires
> syntactical changes to the fork/join (and perhaps to the initial and always) blocks,
> and goes beyond the process control functionality addressed by this proposal.
Yes, and if you don't just go and fix that now we'll end up doing it later
and there will then be two ways of doing something where one would have
been sufficient.
> The parent process can easily avoid race conditions by waiting on the handle
> until it is non-null (a #0 is less elegant but will probably work as well).
Hack.
You shouldn't be creating the race condition.
Kev.
>
> Arturo
>
> ----- Original Message -----
> From: "Kevin Cameron" <dkc@grfx.com>
> To: <sv-ec@eda.org>
> Cc: <Arturo.Salz@synopsys.COM>
> Sent: Sunday, August 17, 2003 11:43 PM
> Subject: Re: [sv-ec] Proposals for EXT-2., EXT-9, and EXT-14
>
>
> > From - Sun Aug 17 15:51:15 PDT 2003
> >
> > A process is a class (i.e. a type). It does not create threads, it simply enables additional
> > control over threads created using the existing mechanisms, including fork..join_any/none.
> >
> > Arturo
>
> So all thread classes are derived from the process class?
>
> The approach you are proposing relies on the thread itself logging
> its existance somewhere the parent thread can pick it up - as in your
> example:
>
> for( int j = 1; j <= N; j++ )
> fork begin job[j] = process::self(); ... ; end
> join_none
> ^^^^^^ outside the thread
>
> - that could lead to some nasty race conditions, since the parent process
> may need the process id before the forked thread gets round to writing it.
>
> I think the syntax needs to be fixed so that the parent can get the id when
> the thread is actually created (and not necessarily started).
>
> Kev.
>
> >
> > ----- Original Message -----
> > From: Kevin Cameron
> > To: sv-ec@eda.org
> > Cc: Arturo Salz
> > Sent: Sunday, August 17, 2003 11:27 AM
> > Subject: Re: [sv-ec] Proposals for EXT-2., EXT-9, and EXT-14
> >
> >
> > Arturo Salz wrote:
> >
> > Greetings,
> >
> > Please find the following = proposals attached:
> > ...
> > EXT-14: Constraints: Constraints.pdf
> >
> > Regards,
> > Arturo
> >
> > How do the threads created by process relate to the threads created bt join-any/none?
> >
> > - or: Why would you want two independent mechanisms to create threads that do don't
> > appear to interact, but probably are the same in implementation? - e.g. await seems to be
> > the same as join but only works in a limited context.
> >
> > Kev.
> >
> >
> > --
> > http://www.grfx.com
> > mailto:dkc@grfx.com
> >
> >
> >
>
>
This archive was generated by hypermail 2b28 : Mon Aug 18 2003 - 09:31:15 PDT