A-Stack Threading Model

The main objective of A-Stack thread pools design is to:

1. Reduce overall number of threads (and therefore number of CPU context switches and memory requirements) while preventing A-Stack Runtime stalls (i.e. waiting for other synchronous activities).
2. Ideally threads must never be in waiting state (in which case it would be enough to have Ncpu threads). Unfortunately it is not always possible due to implementation limitations (e.g. synchronous calls from executed code).

1. SHARED: This pool is shared by all Low-level A-Stack I/O activities and provides so-called “boss” threads. Basically responsible from I/O selectors.
2. SERVER, CLIENT, UPDATER: This pool is a customized implementation java.util.concurrent.ForkJoinPool. The advantage of using ForkJoinPool is that it is capable of monitoring thread activities and adding new threads when needed (and correspondently deleting unneeded threads). Size is controlled by sff.updater.pool.size parameter with default of Ncpu*6. This pool performs most of the [background] work including scheduled activities (see SCHEDULED). It is also provides worker threads low-level A-Stack I/O activities.
3. SCHEDULED: This pool is used for scheduled activities. The size of the pool is controlled by sff.scheduled.pool.size parameter with default of 4. Such low number of threads is possible because all actual work is delegated to UPDATER pool so pool threads are not actually busy.
4. All communication pipelines include communication’s execution handler, which offloads worker threads and ensures fair thread allocation between pipelines (i.e. this pool mostly executes facet scripts associated with pipeline events). The size of the pool is controlled by sff.worker.pool.size parameter with default of Ncpu*2