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

Revision:	1.2
Committed:	Wed Jun 4 11:33:01 2003 UTC (20 years, 11 months ago) by dl
Content type:	text/html
Branch:	MAIN
Changes since 1.1:	+39 -33 lines
Log Message:	Minor documentation updates

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
37	uncaught exceptions, and java.util to better integrate queues.
38	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> Synchronizers
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.PriorityQueue will be added.
79
80	<p> Five implementations in java.util.concurrent support the extended
81	BlockingQueue interface, that defines blocking versions of put and
82	take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,
83	PriorityBlockingQueue, and DelayQueue. Additionally,
84	java.util.concurrent.LinkedQueue supplies an efficient thread-safe
85	non-blocking queue.
86
87	<p> Since the target release is JDK1.5, and generics are slated to be
88	in 1.5, Queues are parametrized on element type. (Also some others
89	below.)
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 interface Callable, the
99	argument/result analog of Runnable.
100
101	<p> Executors provide a framework for executing Runnables. The
102	Executor manages queueing and scheduling of tasks, and creation and
103	teardown of threads. Depending on which concrete Executor class is
104	being used, tasks may execute in a newly created thread, an existing
105	task-execution thread, or the thread calling execute(), and may
106	execute sequentially or concurrently.
107
108	<p> Several concrete implementations of Executor are included in
109	java.util.concurrent, including ThreadPoolExecutor, a flexible thread
110	pool and ScheduledExecutor, which adds support for delayed and
111	periodic task execution. Executor can be used in conjunction with
112	FutureTask (which implements Runnable) to asynchronously start a
113	potentially long-running computation and query the FutureTask to
114	determine if its execution has completed.
115
116	<p> The <tt>Executors</tt> class provides factory methods for all
117	of the types of executors provided in
118	<tt>java.util.concurrent</tt>.
119
120
121	<h2>Locks</h2>
122
123	The Lock interface supports locking disciplines that differ in
124	semantics (reentrant, fair, etc), and that can be used in
125	non-block-structured contexts including hand-over-hand and lock
126	reordering algorithms. This flexibility comes at the price of more
127	awkward syntax. Implementations include ReentrantLock and
128	FairReentrantLock.
129
130	<p>
131	The Locks class additionally supports trylock-designs using builtin
132	locks without needing to use Lock classes. This requires adding new
133	capabilities to builtin locks inside JVMs.
134
135	<p>
136	A ReadWriteLock interface similarly defines locks that may be shared
137	among readers but are exclusive to writers. For this release, only a
138	single implementation, ReentrantReadWriteLock, is planned, since it
139	covers all standard usage contexts. But programmers may create their
140	own implementations to cover nonstandard requirements.
141
142	<h2>Conditions</h2>
143
144	A Condition class provides the kinds of condition variables associated
145	with monitors in other cocurrent languages, as well as pthreads
146	condvars. Their support reduces the need for tricky and/or
147	inefficient solutions to many classic concurrent problems. Conditions
148	also address the annoying problem that Object.wait(msecs) does not
149	return an indication of whether the wait timed out. This leads to
150	error-prone code. Since this method is in class Object, the problem is
151	basically unfixable.
152	<p>
153	To avoid compatibility problems, the names of Condition methods need
154	to be different than Object versions. The downside of this is that
155	people can make the mistake of calling cond.notify instead of
156	cond.signal. However, they will get IllegalMonitorState exceptions if
157	they do, so they can detect the error if they ever run the code.
158
159
160	<h2>Atomic variables</h2>
161
162	The atomic subpackage includes a small library of classes, including
163	AtomicInteger, AtomicLong, and AtomicReference that support variables
164	performinf compareAndSet (CAS) and related atomic operations.
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 class TimeUnit, which provides multiple granularities for
172	both accessing time and performing time-out based operations.
173
174
175	<h2>Synchronizers</h2>
176
177	Five classes aid common special-purpose synchronization idioms.
178	Semaphores and FairSemaphores are classic concurrency tools.
179	CountDownLatches are very simple yet very common objects useful for
180	blocking until a single signal, event, or condition holds.
181	CyclicBarriers are resettable multiway synchronization points very
182	common in some styles of parallel programming. Exchangers allow two
183	threads to exchange objects at a rendezvous point.
184
185
186	<h2>Concurrent Collections</h2>
187
188	JSR 166 will supply a few Collection implementations designed for use
189	in multithreaded contexts: ConcurrentHashMap, CopyOnWriteArrayList,
190	and CopyOnWriteArraySet.
191
192	<h2>Uncaught Exception Handlers</h2>
193
194	The java.lang.Thread class will be modified to allow per-thread
195	installation of handlers for uncaught exceptions. Ths optionally
196	disassociates these handlers from ThreadGroups, which has proven to be
197	too inflexible in many multithreaded programs. (Note that the combination
198	of features in JSR 166 make ThreadGroups even less likely to
199	be used in most programs. Perhaps they will eventually be deprecated.)
200
201	<p> Additionally, ThreadLocals will now support a means to remove a
202	ThreadLocal, which is needed in some thread-pool and worker-thread
203	designs.
204
205	<hr>
206	<address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
207	</body>
208	</html>