úÎ ~oz‚E      !"#$%&'()*+,-./0123456789:;<=>?@ABCD A %, or attempt to acquire or release a . <A resource pool, parameterized against arbitrary user data. 1Create a new Room with some arbitrary user data. $Get the user data associated with a . E1Whether a Claim is to acquire or release a room. Get the  target of a . Get the thread attempting a . F+Approve a claim. This actually acquires a . G Acquire and/>or release some rooms for the duration of a critical section.  which s to , and later release, or ? and later reacquire for the duration of the critical section.  a transaction to F all entering s  a transaction to F all exiting s [ a transaction to run one or more times if and only if this thread is waiting for approval  the critical section  A separate C is generated each time a Room needs to be acquired. The critical 3 section will not enter until every claim has been Fd. `When the critical section exits, an inverse group of claims will be generated, and the critical 4 section will not exit until those claims have been Fd. -It is guaranteed that when and only when all  s have been F!d, the waiting thread will enter 3 (or exit) the critical section. The lock on each  is acquired when it's  is Fd, + not when the critical section is entered.  s may be F2d from any transaction, even from another thread. Get all HI #s that are currently claimimg this . FG  FG  BA maximum limit on the number of threads allowed to claim a room. Should either F or J each claim. F- some claims according to their constraints.      Configuration options for a . A F blocks on a number of predicates when dispatching a job. Generally,  2 should work well for long-running batch jobs and # should work for rapid paced jobs. ' A single STM predicate for the entire . This blocks the entire # until the predicate is satisfied. Z A STM predicate parameterized by priority. This blocks a single priority level, and the ' will skip all tasks at that priority. ? Each task is itself an STM transaction, and can block itself. 6 Pure constraints on priority and ordering inversion. iIf a task is blocked for any reason, the task is skipped and the next task attempted, in priority order. @A predicate that must hold before any task may be pulled from a . JA predicate that must hold before any priority level may be pulled from a . ‚Constrains the greatest allowed difference between the priority of the top-of-queue task and the priority of a task to be pulled. BThe greatest allowed difference between the ideal prioritized FILO/9FIFO ordering of tasks and the actual ordering of tasks. h Setting this too high can introduce a lot of overhead in the presence of a lot of short-running tasks. u Setting this to zero turns off the predicate failover feature, i.e. only the top of queue task will ever be pulled.  Should the O run in FILO or FIFO order. Ordering takes place after prioritization, and won'8t have much effect if priorities are very fine-grained. A prioritized @. Prioritization is least-first, i.e. larger values are nicer. A G is not associated with any working thread, therefore, it is the client'0s responsibility to make sure that every pushed  task is also pulled, or the 9 will stall. There are several ways to accomplish this:  Call %! at least once for every call to #.  Use ( to push every task.  Use ) whenever the  is not empty. _A queue tuned for high throughput and fairness when processing moderate to long running tasks. šA queue tuned for high responsiveness and low priority inversion, but may have poorer long-term throughput and potential to starve some tasks compared to . -True iff this task is poised at the top of it's . " Create a new . #Put a task with it'As priority value onto this queue. Returns a handle to the task. $+The number of tasks pending on this Queue. %!Pull and commit a task from this . &!Pull this task from the top of a , if it is already there. % If this task is top-of-queue, but it's predicates fail, then &# may instead pull a lower-priority . KDon't return until the given % has been pulled from its associated .  This doesn't guarantee that the $ will ever be pulled, even when the  and  are both viable. / You must concurrently arrange for every other  associated with the same  to be pulled, or the  will stall. 'Don't return until the given )s have been pulled from their associated s.  This doesn't guarantee that the $ will ever be pulled, even when the  and  are both viable. / You must concurrently arrange for every other  associated with the same  to be pulled, or the  will stall.  ' can handle lists %s that are distributed among several s, as well as a  s that have A already completed or complete concurrently from another thread. ("Fire and forget"" some tasks on a separate thread. ) Process a  until it is empty.  !"#$%&'()" !#%&'()$ !"#$%&'()*An indirect reference to a -. -Rules for calling G. The two major contexts are 7 , which uses  s to  determine which s are available, and 5., which does not place any constraints on any . /QShould approve a some claims before entering a critical section, as described by G. 0PShould approve a some claims before exiting a critical section, as described by G. 1'A waiting transaction, as described by G. 5Don' t check any  s when acquiring a . 7Require that all   s be satisfied when acquiring a . This is the default. 9 Temporarily , and then release, or , and then acquire, some *s for the duration of a critical section. H A simple example where a room might be used to prevent interleaving of stdout:  room <- newRoom (MaxThreads 1) 7 forkIO $ claim Acquire room $ putStrLn "Hello World!" 5 forkIO $ claim Acquire room $ putStrLn "Foo! Bar!"  *+,-./0123456789 423 -./01*+, 78569*+,+,-./01./0123345667889:*Schedule a task to run from a prioritized . :Tasks that do not actually make claims against any of the ;: s internal s will skip scheduling and the $s will be claimed immediately using 7. This is usually p what you want, in particular in the case where no rooms are actually being claimed, e.g. reentrant scheduling. In other words: Always wrong:  & (Schedule q 2 Default,[room1,room2]) Right:  & Schedule q 2 (Default,[room1,room2]) 4Alternately, if you only want to schedule access to room1, you can place room1 internally and room2 externally. ;:@ will be smart about when to schedule and when not to schedule:  ' (Schedule q 2 (Default,room1), room2) The 8* applies internally and externally to the ;:. In the following example, 6 applies to both room1 and room2: - (Schedule q 2 (Unconstrained,room1), room2) :;:;:;;=A * for a task pool. > Create a new <. <s begin stopped, use B to start.  A  for the backing . A typical value is simple_queue_configuration or .  The user data for the backing . A typical value is    L. Consider using ? if you have no special needs. ?Just create a new <K. The task pool is constrained by the number of capabilities indicated by L. D,The number of threads participating in this  ThreadPool. <=>?@ABCD <=>?@ABCD <=>?@ABCDM     !"#$%&'()*+,-./0123456789:;<=>?@ABBCDEFGHIJKLMNOOPQRSpriority-sync-0.1.0.0 Control.Concurrent.Priority.Room*Control.Concurrent.Priority.RoomConstraint!Control.Concurrent.Priority.Queue$Control.Concurrent.Priority.Schedule$Control.Concurrent.Priority.TaskPool$Control.Concurrent.Priority.RoomCorebaseGHC.ConcControl.Concurrent ClaimModeReleaseAcquireClaimRoomnewRoomuserData claimedRoom claimedThreadinUse MaxThreadsRoomConstraintapproveConstraint approveClaims TaskHandleQueueConfigurationRecordqueue_predicatepriority_indexed_predicateallowed_priority_inversionallowed_ordering_inversion queue_order QueueOrderFILOFIFOQueuefair_queue_configurationfast_queue_configuration isTopOfQueue hasCompleted taskPriority taskQueue pendingTasksnewQueueputTaskloadpullTask pullFromToppullSpecificTasks dispatchTasks flushQueue RoomContextBase baseContextBaseRoomContextBaseRoomContextDataapproveClaimsEnteringapproveClaimsExiting waitingAction RoomGrouproomsOfUserDataUnconstrainedRoomContext UnconstrainedDefaultRoomContextDefaultclaimScheduleTaskPoolschedule newTaskPoolsimpleTaskPoolpoolRoom poolQueue startQueue stopQueueactivity claimModeapproveclaim_ThreadIdretrypullSpecificTasknumCapabilities