ahh@glyph.UUCP (Andy Heffernan) (10/17/89)
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.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/17/89)
Easy. The close down sequence can work like this:
MainTask: Signal SubTask
SubTask:
if (cleanupsignal) {
Cleanup();
Forbid();
Signal(MainTask, whatever)
Wait(0);
}
You can even get rid of the Forbid()... the maintask then
simply RemTask()s the subtask. This kills the subtask in whatever
it's doing (which is nothing... a Wait(0)).
-Mattjesup@cbmvax.UUCP (Randell Jesup) (10/20/89)
In article <483@glyph.UUCP> ahh@glyph.UUCP (Andy Heffernan) writes: > while (FindTask(task_name)) ; /* No raciness */ > > < deallocate stack and Task > Matt showed a very good way. My comment is on your FindTask() busy-loop: this is VERY nasty to the system, as FindTask(name) must Disable() in order to search the task lists. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
ahh@glyph.UUCP (Andy Heffernan) (10/23/89)
In article <8230@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <483@glyph.UUCP> ahh@glyph.UUCP (Andy Heffernan) writes: >> while (FindTask(task_name)) ; /* No raciness */ >> >> < deallocate stack and Task > > > Matt showed a very good way. My comment is on your FindTask() >busy-loop: this is VERY nasty to the system, as FindTask(name) must >Disable() in order to search the task lists. No argument on the nastiness -- that's why I asked. What I wound up doing is having the initiating process issue the kill message, and having the task code (upon receipt of the message) clean up, Forbid(), and then ReplyMsg(). The initiating process gets kicked loose once RemTask() finishes, and then it goes and cleans itself up. Kosher?