Parent Directory
| 
Revision Log
Revision 1.4 - (view) (download) (as text)
| 1 : | dl | 1.1 | <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> |
| 2 : | <html> <head> | ||
| 3 : | <title>Concurrency Utilities</title> | ||
| 4 : | </head> | ||
| 5 : | |||
| 6 : | <body> | ||
| 7 : | |||
| 8 : | dl | 1.3 | <p> Utility classes commonly useful in concurrent programming. This |
| 9 : | package includes a few small standardized extensible frameworks, as | ||
| 10 : | well as some classes that provide useful functionality and are | ||
| 11 : | otherwise tedious or difficult to implement. Here are brief | ||
| 12 : | descriptions of the main components. See also the <tt>locks</tt> and | ||
| 13 : | <tt>atomic</tt> packages. | ||
| 14 : | dl | 1.1 | |
| 15 : | <h2>Executors</h2> | ||
| 16 : | |||
| 17 : | {@link java.util.concurrent.Executor} is a simple standardized | ||
| 18 : | interface for defining custom thread-like subsystems, including thread | ||
| 19 : | pools, asynch-IO, and lightweight task frameworks. Depending on which | ||
| 20 : | concrete Executor class is being used, tasks may execute in a newly | ||
| 21 : | created thread, an existing task-execution thread, or the thread | ||
| 22 : | calling <tt>execute()</tt>, and may execute sequentially or | ||
| 23 : | concurrently. Executors also standardize ways of calling threads that | ||
| 24 : | compute functions returning results, via a {@link | ||
| 25 : | java.util.concurrent.Future}. This is supported in part by defining | ||
| 26 : | interface {@link java.util.concurrent.Callable}, the argument/result | ||
| 27 : | analog of Runnable. | ||
| 28 : | |||
| 29 : | <p> {@link java.util.concurrent.ExecutorService} provides a more | ||
| 30 : | complete framework for executing Runnables. An ExecutorService | ||
| 31 : | manages queueing and scheduling of tasks, and allows controlled | ||
| 32 : | shutdown. The two primary implementations of ExecutorService are | ||
| 33 : | {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and | ||
| 34 : | flexible thread pool and {@link | ||
| 35 : | java.util.concurrent.ScheduledExecutor}, which adds support for | ||
| 36 : | delayed and periodic task execution. These, and other Executors can | ||
| 37 : | be used in conjunction with a {@link java.util.concurrent.FutureTask} | ||
| 38 : | to asynchronously | ||
| 39 : | start a potentially long-running computation and query the FutureTask | ||
| 40 : | to determine if its execution has completed, or cancel it. | ||
| 41 : | |||
| 42 : | <p> The {@link java.util.concurrent.Executors} class provides factory | ||
| 43 : | dl | 1.2 | methods for the most common kinds and configurations of Executors, as |
| 44 : | well as a few utility methods for using them. | ||
| 45 : | dl | 1.1 | |
| 46 : | <h2>Queues</h2> | ||
| 47 : | |||
| 48 : | The java.util.concurrent {@link | ||
| 49 : | java.util.concurrent.ConcurrentLinkedQueue} class supplies an | ||
| 50 : | dl | 1.2 | efficient scalable thread-safe non-blocking FIFO queue. |
| 51 : | dl | 1.1 | |
| 52 : | <p> Five implementations in java.util.concurrent support the extended | ||
| 53 : | {@link java.util.concurrent.BlockingQueue} interface, that defines | ||
| 54 : | blocking versions of put and take: {@link | ||
| 55 : | java.util.concurrent.LinkedBlockingQueue}, {@link | ||
| 56 : | java.util.concurrent.ArrayBlockingQueue}, {@link | ||
| 57 : | java.util.concurrent.SynchronousQueue}, {@link | ||
| 58 : | java.util.concurrent.PriorityBlockingQueue}, and {@link | ||
| 59 : | dl | 1.2 | java.util.concurrent.DelayQueue}. The different classes cover the most |
| 60 : | common usage contexts for producer-consumer, messaging, parallel | ||
| 61 : | tasking, and related concurrent designs. | ||
| 62 : | dl | 1.1 | |
| 63 : | |||
| 64 : | <h2>Timing</h2> | ||
| 65 : | |||
| 66 : | The {@link java.util.concurrent.TimeUnit} class provides multiple | ||
| 67 : | dl | 1.2 | granularities (including nanoseconds) for specifying and controlling |
| 68 : | time-out based operations. Nearly all other classes in the package | ||
| 69 : | contain operations based on time-outs in addition to indefinite waits. | ||
| 70 : | dl | 1.1 | |
| 71 : | dholmes | 1.4 | <p>In all cases that time-outs are used, the time-out specifies the |
| 72 : | minimum time that the method should wait before indicating that it | ||
| 73 : | timed-out. The virtual machine should make a "best effort" | ||
| 74 : | to detect time-outs as soon as possible after they occur. Regardless | ||
| 75 : | of the efforts of the virtual machine, the normal scheduling | ||
| 76 : | mechanisms, and the need to re-acquire locks in many cases, can lead | ||
| 77 : | to an indefinite amount of time elapsing between a time-out being | ||
| 78 : | detected and a thread actually executing again after that time-out. | ||
| 79 : | |||
| 80 : | dl | 1.1 | <h2>Synchronizers</h2> |
| 81 : | |||
| 82 : | Five classes aid common special-purpose synchronization idioms. | ||
| 83 : | {@link java.util.concurrent.Semaphore} and {@link | ||
| 84 : | java.util.concurrent.FairSemaphore} are classic concurrency tools. | ||
| 85 : | {@link java.util.concurrent.CountDownLatch} is very simple yet very | ||
| 86 : | common utility for blocking until a single signal, event, or condition | ||
| 87 : | holds. A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway | ||
| 88 : | synchronization point common in some styles of parallel | ||
| 89 : | programming. An {@link java.util.concurrent.Exchanger} allows two | ||
| 90 : | threads to exchange objects at a rendezvous point. | ||
| 91 : | |||
| 92 : | <h2>Concurrent Collections</h2> | ||
| 93 : | |||
| 94 : | Besides Queues, this package supplies a few Collection implementations | ||
| 95 : | designed for use in multithreaded contexts: {@link | ||
| 96 : | java.util.concurrent.ConcurrentHashMap}, {@link | ||
| 97 : | java.util.concurrent.CopyOnWriteArrayList}, and {@link | ||
| 98 : | java.util.concurrent.CopyOnWriteArraySet}. | ||
| 99 : | |||
| 100 : | <p>The "Concurrent" prefix for classes is a shorthand | ||
| 101 : | indicating several differences from similar "synchronized" | ||
| 102 : | classes. For example <tt>java.util.Hashtable</tt> and | ||
| 103 : | <tt>Collections.synchronizedMap(new HashMap())</tt> are | ||
| 104 : | synchronized. But {@link | ||
| 105 : | java.util.concurrent.ConcurrentHashMap} is "concurrent". | ||
| 106 : | A concurrent collection (among other kinds of classes) is | ||
| 107 : | thread-safe, but not governed by a single exclusion lock. So, in the | ||
| 108 : | particular case of ConcurrentHashMap, it safely permits any number of | ||
| 109 : | concurrent reads as well as a tunable number of concurrent writes. | ||
| 110 : | There may still be a role for "synchronized" classes in some | ||
| 111 : | multithreaded programs -- they can sometimes be useful when you need | ||
| 112 : | to prevent ALL access to a collection via a single lock, at the | ||
| 113 : | expense of much poor scalability. In all other cases, "concurrent" | ||
| 114 : | versions are normally preferable. | ||
| 115 : | |||
| 116 : | <p> Most concurrent Collection implementations (including most Queues) | ||
| 117 : | also differ from the usual java.util conventions in that their Iterators | ||
| 118 : | provide <em>weakly consistent</em> rather than fast-fail traversal. A | ||
| 119 : | weakly consistent iterator is thread-safe, but does not necessarily | ||
| 120 : | freeze the collection while iterating, so it may (or may not) reflect | ||
| 121 : | any updates since the iterator was created. | ||
| 122 : | |||
| 123 : | |||
| 124 : | |||
| 125 : | |||
| 126 : | <hr> | ||
| 127 : | <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address> | ||
| 128 : | dl | 1.3 | <!-- hhmts start --> Last modified: Wed Aug 6 07:18:31 EDT 2003 <!-- hhmts end --> |
| 129 : | dl | 1.1 | </body> </html> |
| Doug Lea | ViewVC Help |
| Powered by ViewVC 1.0.8 |