On Saturday, 96/02/03, Murray Lesser wrote to David Noon about "Pl/i
Multithreading" as follows:

ML> closed.") In my multithreaded program, I am now STOPping the thread
ML> and then ending the "main thread" with an EXIT.  Two supplementary
ML> questions: Should I still DETACH the thread (as well as STOPping it)
ML> before the EXIT?

Hi Murray,

You should always DETACH the thread after you have done a STOP or WAIT
on it. This prevents memory leakage if your "main" program is actually
being called as a subroutine by something else.

ML> Is it very poor programming practice to not even
ML> STOP the thread before the main program EXIT command?

By and large I would say it is poor practice. Normally you should use
WAIT and then DETACH before terminating the main thread. The main
thread's termination code will (or is supposed to) do a STOP and a
DETACH on any straggling threads, but you cannot be certain when that
will be, for the reason I mentioned above.

I think attaching and detaching tasks/threads should be viewed like
opening and closing files: any file your routine opens, it should
close; any thread your routine attaches it should stop/wait and detach.

It is also a requirement to be portable to MVS. The original
multitasking (multithreading in Posix-speak) from IBM was under OS/360,
the 1960's ancestor of MVS. The model there was for hierarchical tasks
(threads) rather than peers, so the task that attached another task was
_obliged_ to detach the daughter task before terminating. There is even
a special system abend (A03) for tasks that fail to detach their
daughter tasks. It is also no coincidence that the OS assembler macros
for creating, waiting on and cleaning up daughter tasks are called
ATTACH, WAIT and DETACH. The way PL/I will implement these statements
on the big iron should be fairly obvious.

And by observing the MVS rules, people writing code under OS/2 will
not only have portable code but avoid memory (and other resource) leaks
too.

ML>     Both threads are currently running on a single-processor system.  I
ML> can't even afford the air conditioning and raised floor necessary
ML> to run your ES/9000 mainframe!

Mine is cheap to air condition, since it's only in my dreams, along
with its 500TB of DASD.

Regards

Dave


 * KWQ/2 1.2i * Pick two: 1)Fast 2)Right 3)Cheap 4)Windows (counts as 2)

--- Maximus/2 3.01