[ViewVC] Annotation of: jsr166/jsr166/intro.html

Revision:	1.3
Committed:	Sun Dec 8 20:28:28 2002 UTC (21 years, 5 months ago) by dl
Content type:	text/html
Branch:	MAIN
Changes since 1.2:	+6 -8 lines
Log Message:	Added DelayQueue; moved Clock

File Contents

#	User	Rev	Content
1	jsr166	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	dl	1.2	<em>
18			Disclaimer - This prototype is experimental code developed as part of
19			JSR166 and made available to the developer community for use
20			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			<p>
28	jsr166	1.1	Package java.util.concurrent contains utility classes that are
29			commonly useful in concurrent programming. Like package java.util, it
30			includes a few small standardized extensible frameworks, as well as
31			some classes that provide useful functionality and are otherwise
32			tedious or difficult to implement. In this JSR, we have been
33			conservative in selecting only those APIs and implementations that are
34			useful enough to encourage nearly all concurrent programmers to use
35			routinely. JSR 166 also includes a few changes and additions in
36			packages outside of java.util.concurrent: java.lang, to address timing
37			and uncaught exceptions, and java.util to better integrate queues, and
38			to make Timers conform to new frameworks. The API covers:
39
40			<ul>
41			<li> Queues
42			<li> Executors
43			<li> Locks
44			<li> Condition variables
45			<li> Atomic variables
46			<li> Timing
47			<li> Barriers
48			<li> Concurrent Collections
49			<li> Uncaught Exception Handlers
50			</ul>
51
52
53			The main rationale for JSR 166 is that threading primitives, such as
54			synchronized blocks, Object.wait and Object.notify, are insufficient
55			for many programming tasks. Currently, developers can use only the
56			concurrency control constructs provided in the Java language
57			itself. These are too low level for some applications, and are
58			incomplete for others. As a result, application programmers are often
59			forced to implement their own concurrency facilities, resulting in
60			enormous duplication of effort creating facilities that are
61			notoriously hard to get right and even harder to optimize. Offering a
62			standard set of concurrency utilities will ease the task of writing a
63			wide variety of multithreaded applications and generally improve the
64			quality of the applications that use them.
65
66			<p>
67			Here are brief descriptions and rationales of the main components.
68			For details see the javadocs at <a
69			href="http://gee.cs.oswego.edu/dl/concurrent/index.html">http://gee.cs.oswego.edu/dl/concurrent/index.html</a>
70
71
72			<h2>Queues</h2>
73
74			A basic (nonblocking) Queue interface that is compatatible with
75			java.util.Collections will be introduced into java.util. Also,
76			although it is at the borders of being in scope of JSR-166,
77			java.util.LinkedList will be adapted to support Queue, and
78			a new non-thread-safe java.util.HeapPriorityQueue will be added.
79
80			<p>
81			Four implementations in java.util.concurrent support the extended
82			BlockingQueue interface, that defines blocking versions of put and
83			take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, and
84			PriorityBlockingQueue. Additionally, java.util.concurrent.LinkedQueue
85			supplies an efficient thread-safe non-blocking queue.
86			<p>
87			Since the target release is JDK1.5, and generics are slated to be in
88			1.5, Queues should be parametrized on element type. (Also some others
89			below.) We are ignoring this for now.
90
91
92			<h2>Executors</h2>
93
94			Executors provide a simple standardized interface for defining custom
95			thread-like subsystems, including thread pools, asynch-IO, and
96			lightweight task frameworks. Executors also standardize ways of
97			calling threads that compute functions returning results, via
98			Futures. This is supported in part by defining java.lang.Callable, the
99			argument/result analog of Runnable.
100
101	dl	1.3	<p> While the Executor framework is intended to be extensible the most
102			commonly used Executor will be ThreadExecutor, which can be configured
103			to act as all sorts of thread pools, background threads, etc. The
104			class is designed to be general enough to suffice for the vast
105			majority of usages, even sophisticated ones, yet also includes methods
106			and functionality that simplify routine usage.
107	jsr166	1.1
108			<p>
109			A few methods will also be added to the java.util.Timer to support
110			Futures, and address other requests for enhancement.
111
112			<h2>Locks</h2>
113
114			The Lock interface supports locking disciplines that differ in
115			semantics (reentrant, semaphore-based, etc), and that can be used in
116			non-block-structured contexts including hand-over-hand and lock
117			reordering algorithms. This flexibility comes at the price of more
118			awkward syntax. Implementations include Semaphore, ReentrantMutex
119			FIFOSemaphore, and CountDownLatch.
120
121			<p>
122			The Locks class additionally supports trylock-designs using builtin
123			locks without needing to use Lock classes. This requires adding new
124			capabilities to builtin locks inside JVMs.
125
126			<p>
127			A ReadWriteLock interface similarly defines locks that may be shared
128			among readers but are exclusive to writers. For this release, only a
129			single implementation, ReentrantReadWriteLock, is planned, since it
130			covers all standard usage contexts. But programmers may create their
131			own implementations to cover nonstandard requirements.
132
133			<h2>Conditions</h2>
134
135			A Condition class provides the kinds of condition variables associated
136			with monitors in other cocurrent languages, as well as pthreads
137			condvars. Their support reduces the need for tricky and/or
138			inefficient solutions to many classic concurrent problems. Conditions
139			also address the annoying problem that Object.wait(msecs) does not
140			return an indication of whether the wait timed out. This leads to
141			error-prone code. Since this method is in class Object, the problem is
142			basically unfixable.
143			<p>
144			To avoid compatibility problems, the names of Condition methods need
145			to be different than Object versions. The downside of this is that
146			people can make the mistake of calling cond.notify instead of
147			cond.signal. However, they will get IllegalMonitorState exceptions if
148			they do, so they can detect the error if they ever run the code.
149			<p>
150			The implementation requires VM magic to atomically suspend and release
151			lock. But it is unlikely to be very challenging for JVM providers,
152			since most layer Java monitors on top of posix condvars or similar
153			low-level functionality anyway.
154
155			<h2>Atomic variables</h2>
156
157			Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and
158			AtomicReference provide simple scalar variables supporting
159			compareAndSwap (CAS) and related atomic operations. These are
160			desparately needed by those performing low-level concurrent system
161			programming, but much less commonly useful in higher-level frameworks.
162
163
164			<h2>Timing</h2>
165
166			Java has always supported sub-millisecond versions of several native
167			time-out-based methods (such as Object.wait), but not methods to
168			actually perform timing in finer-grained units. We address this by
169			introducing java.lang.Clock, which provides multiple granularities for
170			both accessing time and performing time-out based operations.
171
172
173			<h2>Barriers</h2>
174
175			Barriers (multiway synchronization points) are very common in some
176			styles of parallel programming, yet tricky to get right. The two most
177			useful flavors (CyclicBarriers and Exchangers) don't have much of an
178			interface in common, and only have one standard implementation each,
179			so these are simply defined as public classes rather than interfaces
180			and implementations.
181
182
183			<h2>Concurrent Collections</h2>
184
185			There are no new interfaces, but JSR 166 will supply a few Collection
186			implementations designed for use in multithreaded contexts:
187			ConcurrentHashTable, CopyOnWriteArrayList, and CopyOnWriteArraySet.
188
189			<h2>Uncaught Exception Handlers</h2>
190
191			The java.lang.Thread class will be modified to allow per-thread
192			installation of handlers for uncaught exceptions. Ths optionally
193			disassociates these handlers from ThreadGroups, which has proven to be
194			too inflexible in many multithreaded programs. (Note that the combination
195			of features in JSR 166 make ThreadGroups even less likely to
196			be used in most programs. Perhaps they will eventually be deprecated.)
197			<p>
198			Additionally, Threads and ThreadLocals will now support a means to
199			clear and remove ThreadLocals, which is needed in some thread-pool and
200			worker-thread designs.
201
202			<hr>
203			<address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
204			</body>
205			</html>