comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: task synchronization and activation
Date: 19 Feb 2005 15:05:19 -0500
Date: 2005-02-19T15:05:19-05:00	[thread overview]
Message-ID: <wccekfc1fk0.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: 18824603.NgNnWmvhLG@linux1.krischik.com

Martin Krischik <martin@krischik.com> writes:

> Evangelista Sami wrote:
> 
> > Hello all
> > 
> > Why does a task have to wait that all the tasks it created are
> > activated before
> > executing? I am thinking of point 9.particulare RM :
> > 
> > "The task that created the new tasks and initiated their activations
> > (the activator) is blocked until all of these activations complete
> > (successfully or not)."
> > 
> > I can understand that a master has to wait for the tasks he created
> > before finalizing since in the other case it could "free" some memory
> > needed by its children.
> > But i cannot see why this synchronisation after activation is
> > necessary. What is the technical reason?
> 
> So you can make the first rendezvous with that task. It all depends on the
> actual implementation but every task need some internal house keeping
> informations and data structures for inter process comunication and they
> need to be - savely - initialzed.

I don't really agree with that.  For one thing, two tasks that are
activated together can (try to) rendezvous with each other.  So they
have to be prepared for entry calls coming in as soon as they are
activated.  (Of course, these entry calls wait until an appropriate
accept statement.)  So whatever internal housekeeping data structures
are needed must be initialized by the activator (probably during task
*creation*), before activating them.

For another thing, the activator waits until the tasks reach their
"begin".  What's so different about the Ada code before and after the
"begin"?  And the tasks don't wait for each other to *all* reach their
"begin"s -- just the activator waits.

So my answer to Evangelista Sami's question is, "There is no good reason
for this design."  At least, I can't think of one.  This extra
synchronization is just a waste of time, as far as I can tell.

One possibility is that the original designers were thinking about the
fact that exceptions that occur before the "begin" can't be handled.
But I don't see why that makes any real difference.

- Bob



  parent reply	other threads:[~2005-02-19 20:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-19 15:11 task synchronization and activation Evangelista Sami
2005-02-19 16:11 ` Martin Krischik
2005-02-19 18:11   ` Ed Falis
2005-02-19 20:05   ` Robert A Duff [this message]
2005-02-20 10:47     ` Martin Krischik
2005-02-21 19:25     ` Dmitry A. Kazakov
2005-02-21  8:50 ` Jean-Pierre Rosen
2005-02-21 21:55   ` Robert A Duff
2005-02-22  0:01     ` Randy Brukardt
2005-02-22  7:17     ` Jean-Pierre Rosen
2005-02-23  2:24       ` Robert A Duff
2005-02-23  7:58         ` Martin Krischik
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox