Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!glyph!ahh
From: ahh@glyph.UUCP (Andy Heffernan)
Newsgroups: comp.sys.amiga.tech
Subject: Task synchronization
Summary: gizzard
Keywords: spleen
Message-ID: <483@glyph.UUCP>
Date: 17 Oct 89 01:16:39 GMT
Reply-To: ahh@glyph.UUCP (Andy Heffernan)
Organization: Tiffany Fan Club Headquarters
Lines: 36

I am creating sub-tasks with which my main routine will pass messages.

The main routine allocates an individual sub-task's Task structure
and stack space, and starts up the sub-task.  The sub-task will signal
the main routine when it has set up its message port.  Thus the
two tasks have become synchronized, and the main routine can proceed
shoveling messages into the sub-task.

Much later, when all the work gets done, the main routine will tell the
sub-task to kill itself (clean up and return).  The main routine waits
for the sub-task's reply, and then must deallocate the sub-task's Task
structure and stack space, but not until after the sub-task has really
and truly gone away.  This last part is out of my control (unless
I start writing finalPC code), and so there is a race condition.

The best I can come up with to eliminate the race is to do:

	< wait for reply to kill message >
	< getmsg() >

	while (FindTask(task_name)) ;    /* No raciness */

	< deallocate stack and Task >

in the main routine, which relies on RemTask() in the default finalPC
code being atomic, which I believe it is.

So, finally, the question is...
Is there a better way to handle this kind of termination synchronization?

Tenk you vedy mutz.

--
-------------------------------------------------------------------------
  Andy Heffernan					uunet!glyph!ahh
"Today is the first day of the rest of your long, miserable life" -- Dix.