All Packages from org.ematgine.threads.* to org.ematgine.utils.*

Home >> All >> org >> [ ematgine Javadoc ]

•

• org.ematgine: Javadoc index of package org.ematgine.

Package Samples:

• org.ematgine.threads.admin
• org.ematgine.threads.io.ftp
• org.ematgine.threads
• org.ematgine.utils.concurrent
• org.ematgine.utils.encrypter
• org.ematgine.utils.javamail.input
• org.ematgine.utils.javamail.smtp
• org.ematgine.utils.misc.base64
• org.ematgine.utils.parser.files
• org.ematgine.utils.parser.html
• org.ematgine.utils.requests
• org.ematgine.utils.ServiceMngt
• org.ematgine.threads.services.S1000Client.command
• org.ematgine.threads.services.S1000Client.control
• org.ematgine.threads.services.S1000Client.model
• org.ematgine.threads.services.S1000Client.view
• org.ematgine.threads.services.S1000Client
• org.ematgine.threads.services.S1000
• org.ematgine.threads.services.S1005

Classes:

• PooledExecutor: A tunable, extensible thread pool class. The main supported public method is execute(Runnable command) , which can be called instead of directly creating threads to execute commands. Thread pools can be useful for several, usually intertwined reasons: To bound resource use. A limit can be placed on the maximum number of simultaneously executing threads. To manage concurrency levels. A targeted number of threads can be allowed to execute simultaneously. To manage a set of threads performing related tasks. To minimize overhead, by reusing previously constructed Thread objects rather than creating ...
• FJTaskRunner: Specialized Thread subclass for running FJTasks. Each FJTaskRunner keeps FJTasks in a double-ended queue (DEQ). Double-ended queues support stack-based operations push and pop, as well as queue-based operations put and take. Normally, threads run their own tasks. But they may also steal tasks from each others DEQs. The algorithms are minor variants of those used in Cilk and Hood , and to a lesser extent Filaments , but are adapted to work in Java. The two most important capabilities are: Fork a FJTask: Push task onto DEQ Get a task to run (for example within taskYield) If DEQ is not empty, Pop ...
• Sync: Main interface for locks, gates, and conditions. Sync objects isolate waiting and notification for particular logical states, resource availability, events, and the like that are shared across multiple threads. Use of Syncs sometimes (but by no means always) adds flexibility and efficiency compared to the use of plain java monitor methods and locking, and are sometimes (but by no means always) simpler to program with. Most Syncs are intended to be used primarily (although not exclusively) in before/after constructions such as: class X { Sync gate; // ... public void m() { try { gate.acquire(); ...
• Channel: Main interface for buffers, queues, pipes, conduits, etc. A Channel represents anything that you can put items into and take them out of. As with the Sync interface, both blocking (put(x), take), and timeouts (offer(x, msecs), poll(msecs)) policies are provided. Using a zero timeout for offer and poll results in a pure balking policy. To aid in efforts to use Channels in a more typesafe manner, this interface extends Puttable and Takable. You can restrict arguments of instance variables to this type as a way of guaranteeing that producers never try to take, or consumers put. for example: class ...
• SynchronizedVariable: Base class for simple, small classes maintaining single values that are always accessed and updated under synchronization. Since defining them for only some types seemed too arbitrary, they exist for all basic types, although it is hard to imagine uses for some. These classes mainly exist so that you do not have to go to the trouble of writing your own miscellaneous classes and methods in situations including: When you need or want to offload an instance variable to use its own synchronization lock. When these objects are used to replace instance variables, they should almost always be declared ...
• SyncCollection: SyncCollections wrap Sync-based control around java.util.Collections. They are similar in operation to those provided by java.util.Collection.synchronizedCollection, but have several extended capabilities. The Collection interface is conceptually broken into two parts for purposes of synchronization control. The purely inspective reader operations are: size isEmpty toArray contains containsAll iterator The possibly mutative writer operations (which are also the set of operations that are allowed to throw UnsupportedOperationException) are: add addAll remove clear removeAll retainAll SyncCollections ...
• FJTask: Abstract base class for Fork/Join Tasks. FJTasks are lightweight, stripped-down analogs of Threads. Many FJTasks share the same pool of Java threads. This is supported by the FJTaskRunnerGroup and FJTaskRunner classes, that mainly contain methods called only internally by FJTasks. FJTasks support versions of the most common methods found in class Thread, including start(), yield() and join(). However, they don't support priorities, ThreadGroups or other bookkeeping or control methods of class Thread. FJTasks should normally be defined by subclassing and adding a run() method. Alternatively, static ...
• FJTaskRunnerGroup: A stripped down analog of a ThreadGroup used for establishing and managing FJTaskRunner threads. ThreadRunnerGroups serve as the control boundary separating the general world of normal threads from the specialized world of FJTasks. By intent, this class does not subclass java.lang.ThreadGroup, and does not support most methods found in ThreadGroups, since they would make no sense for FJTaskRunner threads. In fact, the class does not deal with ThreadGroups at all. If you want to restrict a FJTaskRunnerGroup to a particular ThreadGroup, you can create it from within that ThreadGroup. The main contextual ...
• Rendezvous: A rendezvous is a barrier that: Unlike a CyclicBarrier, is not restricted to use with fixed-sized groups of threads. Any number of threads can attempt to enter a rendezvous, but only the predetermined number of parties enter and later become released from the rendezvous at any give time. Enables each participating thread to exchange information with others at the rendezvous point. Each entering thread presents some object on entry to the rendezvous, and returns some object on release. The object returned is the result of a RendezvousFunction that is run once per rendezvous, (it is run by the last-entering ...
• Mutex: A simple non-reentrant mutual exclusion lock. The lock is free upon construction. Each acquire gets the lock, and each release frees it. Releasing a lock that is already free has no effect. This implementation makes no attempt to provide any fairness or ordering guarantees. If you need them, consider using one of the Semaphore implementations as a locking mechanism. Sample usage Mutex can be useful in constructions that cannot be expressed using java synchronized blocks because the acquire/release pairs do not occur in the same method or code block. For example, you can use them for hand-over-hand ...
• CondVar: This class is designed for fans of POSIX pthreads programming. If you restrict yourself to Mutexes and CondVars, you can use most of your favorite constructions. Don't randomly mix them with synchronized methods or blocks though. Method names and behavior are as close as is reasonable to those in POSIX. Sample Usage. Here is a full version of a bounded buffer that implements the BoundedChannel interface, written in a style reminscent of that in POSIX programming books. class CVBuffer implements BoundedChannel { private final Mutex mutex; private final CondVar notFull; private final CondVar notEmpty; ...
• VetoableChangeMulticaster: This class is interoperable with java.beans.VetoableChangeSupport, but relies on a streamlined copy-on-write scheme similar to that used in CopyOnWriteArrayList. It also adheres to clarified semantics of add, remove, and fireVetoableChange operations. Sample usage. class Thing { protected Color myColor = Color.red; // an example property protected boolean changePending; // track whether in midst of change // vetoable listeners: protected VetoableChangeMulticaster vetoers = new VetoableChangeMulticaster(this); // Possibly also some ordinary listeners: protected PropertyChangeMulticaster listeners ...
• CyclicBarrier: A cyclic barrier is a reasonable choice for a barrier in contexts involving a fixed sized group of threads that must occasionally wait for each other. (A Rendezvous better handles applications in which any number of threads meet, n-at-a-time.) CyclicBarriers use an all-or-none breakage model for failed synchronization attempts: If threads leave a barrier point prematurely because of timeout or interruption, others will also leave abnormally (via BrokenBarrierException), until the barrier is restart ed. This is usually the simplest and best strategy for sharing knowledge about failures among cooperating ...
• CopyOnWriteArrayList: This class implements a variant of java.util.ArrayList in which all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array. This is ordinarily too costly, but it becomes attractive when traversal operations vastly overwhelm mutations, and, especially, when you cannot or don't want to synchronize traversals, yet need to preclude interference among concurrent threads. The iterator method uses a reference to the state of the array at the point that the iterator was created. This array never changes during the lifetime of the iterator, so interference ...
• Semaphore: Base class for counting semaphores. Conceptually, a semaphore maintains a set of permits. Each acquire() blocks if necessary until a permit is available, and then takes it. Each release adds a permit. However, no actual permit objects are used; the Semaphore just keeps a count of the number available and acts accordingly. A semaphore initialized to 1 can serve as a mutual exclusion lock. Different implementation subclasses may provide different ordering guarantees (or lack thereof) surrounding which threads will be resumed upon a signal. The default implementation makes NO guarantees about the ...
• CopyOnWriteArraySet: This class implements a java.util.Set that uses a CopyOnWriteArrayList for all of its operations. Thus, it shares the same basic properties: It is best suited for applications in which set sizes generally stay small, read-only operations vastly outnumber mutative operations, and you need to prevent interference among threads during traversal. Mutative operations(add, set, remove, etc) are fairly expensive since they usually entail copying the entire underlying array. Loops involving repeated element-by-element mutative operations are so expensive that they should generally be avoided. Iterators ...
• WaitFreeQueue: A wait-free linked list based queue implementation, adapted from the algorithm described in Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms by Maged M. Michael and Michael L. Scott. This implementation is not strictly wait-free since it relies on locking for basic atomicity and visibility requirements. Locks can impose unbounded waits, although this should not be a major practical concern here since each lock is held for the duration of only a few statements. (However, the overhead of using so many locks can make it less attractive than other Channel implementations ...
• ReadWriteLock: ReadWriteLocks maintain a pair of associated locks. The readLock may be held simultanously by multiple reader threads, so long as there are no writers. The writeLock is exclusive. ReadWrite locks are generally preferable to plain Sync locks or synchronized methods in cases where: The methods in a class can be cleanly separated into those that only access (read) data vs those that modify (write). Target applications generally have more readers than writers. The methods are relatively time-consuming (as a rough rule of thumb, exceed more than a hundred instructions), so it pays to introduce a bit ...
• WaiterPreferenceSemaphore: An implementation of counting Semaphores that enforces enough fairness for applications that need to avoid indefinite overtaking without necessarily requiring FIFO ordered access. Empirically, very little is paid for this property unless there is a lot of contention among threads or very unfair JVM scheduling. The acquire method waits even if there are permits available but have not yet been claimed by threads that have been notified but not yet resumed. This makes the semaphore almost as fair as the underlying Java primitives allow. So, if synch lock entry and notify are both fair so is the semaphore ...
• ClockDaemon: A general-purpose time-based daemon, vaguely similar in functionality to common system-level utilities such as at (and the associated crond) in Unix. Objects of this class maintain a single thread and a task queue that may be used to execute Runnable commands in any of three modes -- absolute (run at a given time), relative (run after a given delay), and periodic (cyclically run with a given delay). All commands are executed by the single background thread. The thread is not actually started until the first request is encountered. Also, if the thread is stopped for any reason, one is started upon ...
• PropertyChangeMulticaster: This class is interoperable with java.beans.PropertyChangeSupport, but relies on a streamlined copy-on-write scheme similar to that used in CopyOnWriteArrayList. This leads to much better performance in most event-intensive programs. It also adheres to clarified semantics of add and remove operations. Sample usage. class Thing { protected Color myColor = Color.red; // an example property protected PropertyChangeMulticaster listeners = new PropertyChangeMulticaster(this); // registration methods, including: void addListener(PropertyChangeListener l) { // Use the `ifAbsent' version to avoid duplicate ...
• ReentrantWriterPreferenceReadWriteLock: A writer-preference ReadWriteLock that allows writers to reacquire read or write locks in the style of a ReentrantLock. Readers are not allowed until all write locks held by the writing thread have been released. Readers may also reacquire read locks, but not write locks. Among other applications, reentrancy can be useful when write locks are held during calls or callbacks to methods that perform reads under read locks. Sample usage . Here is a code sketch showing how to exploit reentrancy to perform lock downgrading after updating a cache: class CachedData { Object data; volatile boolean cacheValid; ...
• TimeDaemon: A general-purpose timer daemon, vaguely similar in functionality common system-level utilities like at (and the associated crond) in Unix. Objects of this class maintain a single thread and a task queue that may be used to execute Runnable commands in any of three modes -- absolute (run at a given time), relative (run after a given delay), and periodic (cyclically run with a given delay). All commands are executed by the single background thread. The thread is not actually started until the first request is encountered. Also, if the thread is stopped for any reason, one is started upon the next ...
• BoundedPriorityQueue: A heap-based priority queue, using semaphores for concurrency control. The take operation returns the least element with respect to the given ordering. (If more than one element is tied for least value, one of them is arbitrarily chosen to be returned -- no guarantees are made for ordering across ties.) Ordering follows the JDK1.2 collection conventions: Either the elements must be Comparable, or a Comparator must be supplied. Comparison failures throw ClassCastExceptions during insertions and extractions. The implementation uses a standard array-based heap algorithm, as described in just about ...
• CountDown: A CountDown can serve as a simple one-shot barrier. A Countdown is initialized with a given count value. Each release decrements the count. All acquires block until the count reaches zero. Upon reaching zero all current acquires are unblocked and all subsequent acquires pass without blocking. This is a one-shot phenomenon -- the count cannot be reset. If you need a version that resets the count, consider using a Barrier. Sample usage. Here are a set of classes in which a group of worker threads use a countdown to notify a driver when all threads are complete. class Worker implements Runnable { ...

Home | Contact Us | Privacy Policy | Terms of Service