[Haskell-cafe] ANN: priority-sync-0.1.0.1: Cooperative task prioritization.

[Christopher Lane Hinson]

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/priority-sync

$ cabal install priority-sync

git clone http://www.downstairspeople.org/git/priority-sync.git

Feedback will be greatly appreciated.  This package is a spin-off from my 
work on roguestar, where I need to do significant background processing 
while retaining enough resources to perform smooth animation.

The following is the front-page documentation for the package.

In a simple use case, we want to run some expensive tasks in prioritized 
order, so that only one task is running on each CPU (or hardware thread) 
at any time. For this simple case, four operations are needed: 
simpleTaskPool, schedule, claim, and startQueue.

let expensiveTask = threadDelay 1000000
pool <- simpleTaskPool
forkIO $ claim Acquire (schedule pool 1) $ putStrLn "Task 1 started . . ." >> expensiveTask >> putStrLn "Task 1 completed."
forkIO $ claim Acquire (schedule pool 3) $ putStrLn "Task 3 started . . ." >> expensiveTask >> putStrLn "Task 3 completed."
forkIO $ claim Acquire (schedule pool 2) $ putStrLn "Task 2 started . . ." >> expensiveTask >> putStrLn "Task 2 completed."
threadDelay 100000  -- contrive to wait for all tasks to become enqueued
putStrLn "Starting pool: "
startQueue pool
threadDelay 4000000 -- contrive to wait for all tasks to become dequeued

A TaskPool combines Rooms and Queues in an efficient 
easy-to-use-interface.

Rooms provide fully reentrant synchronization to any number of threads 
based on arbitrary resource constraints. For example, the Room from a 
simpleTaskPool is constrained by GHC.numCapabilities.

Queues provide task prioritization. A Queue systematically examines (to a 
configurable depth) all waiting threads with their priorities and resource 
constraints and wakes the most eagerly prioritized thread whose 
constraints can be satisfied.

TaskPools are not thread pools. The concept is similar to IO Completion 
Ports. There are no worker threads. If a number of threads are waiting, 
the thread that is most likely to be processed next is woken and 
temporarily serves as a working thread.

Rooms, Queues, and TaskPools are backed by carefully written STM (software 
transactional memory) transactions.

A salient feature is that, because any thread can participate, a TaskPool 
supports both bound threads and threads created with forkOnIO.

Friendly,
--Lane