Task dependence and termination

Task dependence and termination

[Arny B. Engelson]

   Would anyone care to comment on the following situation?:

   I have a Semaphore task which uses a looping select statement with a
Terminate alternative.  This task is declared in a library package.
I use the Semaphore in two different records (Rec1, Rec2) which are
declared in another library package.  An access pointer to Rec2 (Rec2p)
is also declared in this package.  The main program creates objects of
type Rec1 and Rec2p.  If I am reading LRM 9.4 correctly, none of the
Semaphores will ever self-terminate (paragraphs 7-8 and 2).  Moving the
Rec2p declaration to the main program should cause those Semaphores to
terminate but not the Rec1 Semaphores.  Am I right so far?
   Next step.  Will creating a Die entry in the Semaphore that causes it
to exit the loop actually get it to terminate, or will it hang at the
end statement?  It should Die, but this is a clumsy way of doing things.

   Any intelligent comments are welcome.  Please don't suggest moving the
Semaphore declaration to the main program.

THE CHALLENGE:
   Actually this came about because of a problem trying to terminate a
task that very stubbornly refuses to die.  The task is declared in the
main program.  A pointer to it is declared within a package in the main
program.  The main program is "begin null; end;".  When all other tasks
in the program are terminated ('terminated = True), this one hangs at its
end statement.  If anyone particularly knowledgeable about tasking would
like to take a crack at it, I'd be glad to describe it (and possibly
furnish a reduced version).


Arny B. Engelson
{ ihnp4 | bonnie | clyde } wayback!arny
(201) 386-4816

Re: Task dependence and termination

[stt]

The language review board has been worrying about the termination
of tasks which depend on library units.  The preliminary
decision (aka "interpretation") is to require that the program
wait for such tasks to terminate before returning to the
host operating system.  I think this also implies that
"group termination" rules apply, meaning that if all such
tasks are either terminated or waiting on open terminate
alternatives, then they will all terminate as a group.