WorkerThreadsDoc.tioga
Copyright Ó 1993 by Xerox Corporation. All rights reserved.
Created by Christian Jacobi, April 2, 1993
Christian Jacobi, April 13, 1993 11:46 am PDT
The package has not yet been seriously used
While this package is new and clients are very limited, I want to keep the right to do changes to the interface if required by clients.
The interface is the documentation.
Here some highlights only
With the availability of multiprocessors we have a desire to use parallel processing to reduce latency. However, for many applications there is no given natural number of threads. If an unbounded number of threads is used too much scheduling or too much stack space may be required. This package helps such application in two non trivial tasks: limiting the number of threads, and, finding an appropriate limit.
The usual disclaimers hold:
Enqueued procedures must be global.
Priority is set once after forking but is never again touched or reset.
If all the available threads in a pool are blocked, no further progress will be made.
It is dangerous for a worker thread to wait for an event to be generated by another worker thread, as the pool might not have enough virtual threads left to guarantee the other worker beeing forked.
Only a fraction of all possible wedges are detected.
Design rationale for pool versus
LIST
OF Activity types:
Typical usage is to allocate a pool statically per client package, but, build a LIST OF Activity for each invocation of a client procedure.
More design rationale and internal documentation
Appropos "finding an appropriate limit": The package falls short on providing a real usable value. However, it succeeeds in funneling this information into a single, application independent place.