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

Revision:	1.2
Committed:	Fri Oct 25 22:55:44 2002 UTC (21 years, 6 months ago) by dl
Content type:	text/html
Branch:	MAIN
Changes since 1.1:	+11 -0 lines
Log Message:	Added disclaimer to intro.html

File Contents

#	Content
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	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	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	<p> While the Executor framework is intended to be extensible (so
102	includes for example, AbstractExecutor that simplifies construction of
103	new implementations), the most commonly used Executor will be
104	ThreadExecutor, which can be configured to act as all sorts of thread
105	pools, background threads, etc. The class is designed to be general
106	enough to suffice for the vast majority of usages, even sophisticated
107	ones, yet also includes methods and functionality that simplify
108	routine usage.
109
110	<p>
111	A few methods will also be added to the java.util.Timer to support
112	Futures, and address other requests for enhancement.
113
114	<h2>Locks</h2>
115
116	The Lock interface supports locking disciplines that differ in
117	semantics (reentrant, semaphore-based, etc), and that can be used in
118	non-block-structured contexts including hand-over-hand and lock
119	reordering algorithms. This flexibility comes at the price of more
120	awkward syntax. Implementations include Semaphore, ReentrantMutex
121	FIFOSemaphore, and CountDownLatch.
122
123	<p>
124	The Locks class additionally supports trylock-designs using builtin
125	locks without needing to use Lock classes. This requires adding new
126	capabilities to builtin locks inside JVMs.
127
128	<p>
129	A ReadWriteLock interface similarly defines locks that may be shared
130	among readers but are exclusive to writers. For this release, only a
131	single implementation, ReentrantReadWriteLock, is planned, since it
132	covers all standard usage contexts. But programmers may create their
133	own implementations to cover nonstandard requirements.
134
135	<h2>Conditions</h2>
136
137	A Condition class provides the kinds of condition variables associated
138	with monitors in other cocurrent languages, as well as pthreads
139	condvars. Their support reduces the need for tricky and/or
140	inefficient solutions to many classic concurrent problems. Conditions
141	also address the annoying problem that Object.wait(msecs) does not
142	return an indication of whether the wait timed out. This leads to
143	error-prone code. Since this method is in class Object, the problem is
144	basically unfixable.
145	<p>
146	To avoid compatibility problems, the names of Condition methods need
147	to be different than Object versions. The downside of this is that
148	people can make the mistake of calling cond.notify instead of
149	cond.signal. However, they will get IllegalMonitorState exceptions if
150	they do, so they can detect the error if they ever run the code.
151	<p>
152	The implementation requires VM magic to atomically suspend and release
153	lock. But it is unlikely to be very challenging for JVM providers,
154	since most layer Java monitors on top of posix condvars or similar
155	low-level functionality anyway.
156
157	<h2>Atomic variables</h2>
158
159	Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and
160	AtomicReference provide simple scalar variables supporting
161	compareAndSwap (CAS) and related atomic operations. These are
162	desparately needed by those performing low-level concurrent system
163	programming, but much less commonly useful in higher-level frameworks.
164
165
166	<h2>Timing</h2>
167
168	Java has always supported sub-millisecond versions of several native
169	time-out-based methods (such as Object.wait), but not methods to
170	actually perform timing in finer-grained units. We address this by
171	introducing java.lang.Clock, which provides multiple granularities for
172	both accessing time and performing time-out based operations.
173
174
175	<h2>Barriers</h2>
176
177	Barriers (multiway synchronization points) are very common in some
178	styles of parallel programming, yet tricky to get right. The two most
179	useful flavors (CyclicBarriers and Exchangers) don't have much of an
180	interface in common, and only have one standard implementation each,
181	so these are simply defined as public classes rather than interfaces
182	and implementations.
183
184
185	<h2>Concurrent Collections</h2>
186
187	There are no new interfaces, but JSR 166 will supply a few Collection
188	implementations designed for use in multithreaded contexts:
189	ConcurrentHashTable, CopyOnWriteArrayList, and CopyOnWriteArraySet.
190
191	<h2>Uncaught Exception Handlers</h2>
192
193	The java.lang.Thread class will be modified to allow per-thread
194	installation of handlers for uncaught exceptions. Ths optionally
195	disassociates these handlers from ThreadGroups, which has proven to be
196	too inflexible in many multithreaded programs. (Note that the combination
197	of features in JSR 166 make ThreadGroups even less likely to
198	be used in most programs. Perhaps they will eventually be deprecated.)
199	<p>
200	Additionally, Threads and ThreadLocals will now support a means to
201	clear and remove ThreadLocals, which is needed in some thread-pool and
202	worker-thread designs.
203
204	<hr>
205	<address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
206	</body>
207	</html>