[Haskell-cafe] Re: ANN: priority-sync-0.1.0.1: Cooperative task
relapse.dev at gmx.com
Wed May 13 19:51:28 EDT 2009
Christopher Lane Hinson wrote:
> $ 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.
Is 'claim' the only way to execute tasks?
Lets say you create a task pool for 1 hardware thread.
pool <- newTaskPool fast_queue_configuration 1 ()
If a task blocks/sleeps while holding a claim, none of the other tasks
can run right?
Is it possible to create a task pool for 2 hardware threads having one
task dominate 1 CPU (render thread), and have other tasks multiplex IO
on the other CPU __without stalling each other when blocked__? What
happens if you release the room claim before blocking in IO? Does the
thread schedule on a random CPU?
More information about the Haskell-Cafe