util
A trait for a barrier that can be used by callers to synchronize on an event by waiting for the barrier to be set.
A context for testing concurrent code that provides: 1) an ExecutionContext that keeps track of the number of active and completed Runnables 2) a Timer for tracking elapsed duration since start of test 3) a SerializationSchedule for detecting order of execution of events 4) a precision delay function that accumulates any delay error
A base trait for a future that delegates its implementation to another delegate future
A trait for a latch that can be set once to synchronize events that are waiting on the barrier.
A trait for a non-blocking lock that ensures a synchronous execution schedule for all callers.
A trait for a progress reporter that reports progress only at the specified report interval
A case class to report progress in a computation
A case class to report progress in a computation
the count of iterations completed so far
Some(total iterations in computation) or None if the computation has an unknown size
the time in nanoseconds returned by System.nanoTime when the computation was started
A trait to decide whether to retry a failure in a task.
A trait to decide whether to retry a failure in a task. Tasks are identified by their sequence number.
Note: implementations must be thread safe.
A trait for a non-blocking semaphore that ensures limiting concurrent execution to tasks that have been granted the requested number of permits from a limited pool of permits.
A trait for a non-blocking semaphore that ensures limiting concurrent execution to tasks that have been granted the requested number of permits from a limited pool of permits. The acquire method is used to request the execution of a task once the requested number of permits become available. If the permits are not immediately available, the request is placed into a FIFO queue while waiting for permits to become available. The permit pool size is typically static with permits released back to the pool upon completion of tasks. However, some implementations may have dynamic sized pools that expend permits instead of releasing them, replenishing permits through some other mechanism.
Note1: Because Semaphore accepts a function to the task to run, it is not possible for callers to double lock, double release or forget to release permits. Note2: Semaphore is NOT reentrant Note3: Semaphore should never be used when other options make more sense. Semaphore is designed for synchronizing many tasks (100+) and/or long running tasks (10ms+). Unlike other options, Semaphore does not block and consume a thread while waiting for permits to become available. However, Semaphore is not the most performant option.
A trait used to guarantee a series of unordered tasks occur sequentially.
A trait used to guarantee a series of unordered tasks occur sequentially. By associating a sequence number with each task, the sequencer can determine whether to immediately run a task or queue the task for later. When a task has been queued and the sequence number for that task has been reached, the task is removed from the queue and executed. The sequence number is only advanced after the task completes.
Note: it is assumed each task has a unique sequence number. A request to execute a task with a sequence number that is less than the current sequence number causes an IllegalArgumentException to be thrown.
A case class for determining the ordering of instantaneous and time-spanning real-time events
A case class for determining the ordering of instantaneous and time-spanning real-time events
event identifier type
A trait for a simple progress reporter that accumulates total progress from completed reports and makes a report each time there is progress during a task.
A trait for listening to the progress of a task that consists of one or more discrete steps.
A trait for listening to the progress of a task that consists of one or more discrete steps. Each step is identified by a sequence number.
Note: implementations must be thread safe
A trait for controlling the throttle value of some operation
A trait that ensures a series of tasks run no faster than the throttle setting.
A trait that ensures a series of tasks run no faster than the throttle setting. Callers schedule tasks by calling the run method. If at least throttle setting nanoseconds have passed since the last task completed, the supplied function is immediately executed, otherwise it is scheduled for execution once throttle nanoseconds have expired. Tasks scheduled at the same time for later execution will be executed in a FIFO manner. Throttler guarantees that all tasks will have at least throttle nanoseconds separating their completion. However, it can not guarantee that the elapsed time between tasks will not be greater than the throttle setting.
A trait for a non-blocking lock that ensures a synchronous execution schedule for all callers. A caller calls the lock method to execute a task synchronously once the lock is available. Simultaneous tasks are placed in a FIFO queue while awaiting execution.
Note1: Because Lock accepts a function to the task to run, it is not possible for callers to double lock, double release or forget to release the lock. Note2: Lock is NOT reentrant Note3: Lock should never be used when other locking options make more sense. Lock is designed for synchronizing many tasks (100+) and/or long running tasks (10ms+). Unlike other locking options, Lock does not block and consume a thread while waiting for the lock to become available. However, Lock is not the most performant option.