[cvs] / jsr166 / src / main / intro.html Repository:
ViewVC logotype

Annotation of /jsr166/src/main/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.6 - (view) (download) (as text)

1 : tim 1.1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 :     <html>
3 :     <head>
4 :     <title>JSR 166 Snapshot Introduction.</title>
5 :     </head>
6 :    
7 :     <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8 :     <h1>JSR 166 Snapshot Introduction.</h1>
9 :    
10 :     by <a href="http://gee.cs.oswego.edu/dl">Doug Lea</a>
11 :     <p>
12 :    
13 :     To join a mailing list discussing this JSR, go to:
14 :     <A HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A> .
15 :    
16 :     <p>
17 :     <em>
18 :     Disclaimer - This prototype is experimental code developed as part of
19 : dl 1.3 JCP JSR166 and made available to the developer community for use
20 : tim 1.1 as-is. It is not a supported product. Use it at your own risk. The
21 :     specification, language and implementation are subject to change as a
22 :     result of your feedback. Because these features have not yet been
23 :     approved for addition to the Java language, there is no schedule for
24 :     their inclusion in a product.
25 :     </em>
26 :    
27 : dl 1.3 <p> Package java.util.concurrent contains utility classes commonly
28 :     useful in concurrent programming. Like package java.util, it includes
29 :     a few small standardized extensible frameworks, as well as some
30 :     classes that provide useful functionality and are otherwise tedious or
31 :     difficult to implement. JSR166 also includes a few changes and
32 :     additions in packages outside of java.util.concurrent: java.lang, to
33 :     address uncaught exceptions, and java.util to better integrate with
34 :     collections. Since the target release is JDK1.5, many APIs use
35 :     generics to parameterize on types. Here are brief descriptions of the
36 :     main components.
37 : tim 1.1
38 : dl 1.3 <h2>Executors</h2>
39 :    
40 :     {@link java.util.concurrent.Executor} is a simple standardized
41 :     interface for defining custom thread-like subsystems, including thread
42 :     pools, asynch-IO, and lightweight task frameworks. Depending on which
43 :     concrete Executor class is being used, tasks may execute in a newly
44 :     created thread, an existing task-execution thread, or the thread
45 :     calling <tt>execute()</tt>, and may execute sequentially or
46 :     concurrently. Executors also standardize ways of calling threads that
47 :     compute functions returning results, via a {@link
48 :     java.util.concurrent.Future}. This is supported in part by defining
49 :     interface {@link java.util.concurrent.Callable}, the argument/result
50 :     analog of Runnable.
51 :    
52 :     <p> {@link java.util.concurrent.ExecutorService} provides a more
53 :     complete framework for executing Runnables. An ExecutorService
54 :     manages queueing and scheduling of tasks, and allows controlled
55 :     shutdown. The two primary implementations of ExecutorService are
56 :     {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and
57 :     flexible thread pool and {@link
58 :     java.util.concurrent.ScheduledExecutor}, which adds support for
59 :     delayed and periodic task execution. These, and other Executors can
60 : dholmes 1.5 be used in conjunction with a {@link java.util.concurrent.FutureTask}
61 :     to asynchronously
62 : dl 1.3 start a potentially long-running computation and query the FutureTask
63 :     to determine if its execution has completed, or cancel it.
64 :    
65 :     <p> The {@link java.util.concurrent.Executors} class provides factory
66 :     methods for the most common kinds and styles of Executors, as well as
67 :     a few utilities methods for using them.
68 : tim 1.1
69 :     <h2>Queues</h2>
70 :    
71 : dl 1.3 A basic (nonblocking) {@link java.util.Queue} interface extending
72 :     java.util.Collection is introduced into java.util. Existing class
73 :     java.util.LinkedList is adapted to support Queue, and a new
74 : dl 1.6 non-thread-safe {@link java.util.PriorityQueue} is added. The
75 :     java.util.concurrent {@link
76 :     java.util.concurrent.ConcurrentLinkedQueue} class supplies an
77 :     efficient sclable thread-safe non-blocking FIFO queue, and {@link
78 :     java.util.concurrent.ConcurrentLinkedStack} provides a similar
79 :     non-blocking LIFO stack.
80 : tim 1.1
81 :     <p> Five implementations in java.util.concurrent support the extended
82 : dl 1.3 {@link java.util.concurrent.BlockingQueue} interface, that defines
83 :     blocking versions of put and take: {@link
84 :     java.util.concurrent.LinkedBlockingQueue}, {@link
85 :     java.util.concurrent.ArrayBlockingQueue}, {@link
86 :     java.util.concurrent.SynchronousQueue}, {@link
87 : dholmes 1.5 java.util.concurrent.PriorityBlockingQueue}, and
88 :     {@link java.util.concurrent.DelayQueue}.
89 : tim 1.1
90 :    
91 :     <h2>Locks</h2>
92 :    
93 : dl 1.3 The {@link java.util.concurrent.Lock} interface supports locking
94 :     disciplines that differ in semantics (reentrant, fair, etc), and that
95 :     can be used in non-block-structured contexts including hand-over-hand
96 :     and lock reordering algorithms. This flexibility comes at the price of
97 :     more awkward syntax. Implementations include {@link
98 :     java.util.concurrent.ReentrantLock} and {@link
99 :     java.util.concurrent.FairReentrantLock}.
100 :    
101 :     <p> The {@link java.util.concurrent.Locks} class additionally supports
102 :     some common trylock-designs using builtin locks.
103 :    
104 :     <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly
105 :     defines locks that may be shared among readers but are exclusive to
106 :     writers. Only a single implementation, {@link
107 :     java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
108 : tim 1.1 covers all standard usage contexts. But programmers may create their
109 :     own implementations to cover nonstandard requirements.
110 :    
111 :     <h2>Conditions</h2>
112 :    
113 : dl 1.3 The {@link java.util.concurrent.Condition} interface describes the
114 :     kinds of condition variables associated with monitors in other
115 :     concurrent languages, as well as pthreads-style condvars. Their
116 :     support reduces the need for tricky and/or inefficient solutions to
117 :     many classic concurrent problems. To avoid compatibility problems,
118 :     the names of Condition methods are different than Object versions.
119 : tim 1.1
120 : dl 1.3 <h2>Atomics</h2>
121 : tim 1.1
122 : dl 1.2 The atomic subpackage includes a small library of classes, including
123 : dl 1.3 AtomicInteger, AtomicLong, and AtomicReference that support
124 :     compareAndSet (CAS) and related atomic operations.
125 : tim 1.1
126 :     <h2>Timing</h2>
127 :    
128 : dl 1.3 The {@link java.util.concurrent.TimeUnit} class provides multiple
129 :     granularities (including nanoseconds) for both accessing time and
130 :     performing time-out based operations.
131 : tim 1.1
132 :     <h2>Synchronizers</h2>
133 :    
134 :     Five classes aid common special-purpose synchronization idioms.
135 : dl 1.3 {@link java.util.concurrent.Semaphore} and {@link
136 :     java.util.concurrent.FairSemaphore} are classic concurrency tools.
137 :     {@link java.util.concurrent.CountDownLatch} is very simple yet very
138 :     common utility for blocking until a single signal, event, or condition
139 : dholmes 1.5 holds. A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway
140 : dl 1.3 synchronization point common in some styles of parallel
141 :     programming. An {@link java.util.concurrent.Exchanger} allows two
142 : dl 1.2 threads to exchange objects at a rendezvous point.
143 : tim 1.1
144 :     <h2>Concurrent Collections</h2>
145 :    
146 : dl 1.6 Besides Queues, this package supplies a few Collection implementations
147 :     designed for use in multithreaded contexts: {@link
148 : dl 1.3 java.util.concurrent.ConcurrentHashMap}, {@link
149 :     java.util.concurrent.CopyOnWriteArrayList}, and {@link
150 :     java.util.concurrent.CopyOnWriteArraySet}.
151 :    
152 : dl 1.6 <p>The "Concurrent" prefix for classes is a shorthand
153 :     indicating several differences from similar "synchronized"
154 :     classes. For example <tt>java.util.Hashtable</tt> and
155 :     <tt>Collections.synchronizedMap(new HashMap())</tt> are
156 :     synchronized. But {@link
157 :     java.util.concurrent.ConcurrentHashMap} is "concurrent".
158 :     A concurrent collection (among other kinds of classes) is
159 :     thread-safe, but not governed by a single exclusion lock. So, in the
160 :     particular case of ConcurrentHashMap, it safely permits any number of
161 :     concurrent reads as well as a tunable number of concurrent writes.
162 :     There may still be a role for "synchronized" classes in some
163 :     multithreaded programs -- they can sometimes be useful when you need
164 :     to prevent ALL access to a collection via a single lock, at the
165 :     expense of much poor scalability. In all other cases, "concurrent"
166 :     versions are normally preferable.
167 :    
168 : dl 1.3 <p> Most concurrent Collection implementations (including most Queues)
169 : dl 1.6 also differ from the usual java.util conventions in that their Iterators
170 : dl 1.3 provide <em>weakly consistent</em> rather than fast-fail traversal. A
171 :     weakly consistent iterator is thread-safe, but does not necessarily
172 :     freeze the collection while iterating, so it may (or may not) reflect
173 :     any updates since the iterator was created.
174 : tim 1.1
175 :     <h2>Uncaught Exception Handlers</h2>
176 :    
177 : dl 1.3 The java.lang.Thread class is modified to allow per-thread
178 : tim 1.1 installation of handlers for uncaught exceptions. Ths optionally
179 :     disassociates these handlers from ThreadGroups, which has proven to be
180 : dl 1.3 too inflexible in many multithreaded programs. (Note that the
181 :     combination of features in JSR166 make ThreadGroups even less likely
182 :     to be used in most programs. Perhaps they will eventually be
183 :     deprecated.)
184 : dl 1.2
185 : dl 1.3 <p> Additionally, java.lang.ThreadLocal now supports a means to remove
186 :     a ThreadLocal, which is needed in some thread-pool and worker-thread
187 : dl 1.2 designs.
188 : tim 1.1
189 :     <hr>
190 :     <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
191 :     </body>
192 :     </html>

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8