ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/src/main/intro.html
(Generate patch)

Comparing jsr166/src/main/intro.html (file contents):
Revision 1.4 by dl, Tue Jun 24 14:33:52 2003 UTC vs.
Revision 1.12 by dl, Sat Aug 9 20:00:07 2003 UTC

# Line 1 | Line 1
1   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2   <html>
3   <head>
4 <   <title>JSR 166 Snapshot Introduction.</title>
4 >   <title>JSR 166 Introduction.</title>
5    </head>
6  
7    <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8 <  <h1>JSR 166 Snapshot Introduction.</h1>
8 >  <h1>JSR 166 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 < JCP 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> 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 <
38 < <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 < be used in conjunction with a {@link FutureTask} to asynchronously
61 < start a potentially long-running computation and query the FutureTask
62 < to determine if its execution has completed, or cancel it.
63 <
64 < <p> The {@link java.util.concurrent.Executors} class provides factory
65 < methods for the most common kinds and styles of Executors, as well as
66 < a few utilities methods for using them.
13 > This is an updated version of the specification submitted for JCP
14 > Community Draft review.  To check for further updates, access a
15 > preliminary prototype release of main functionality, or join a mailing
16 > list discussing this JSR, go to: <A
17 > HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
18 > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
19 > .  <p>
20 >
21 > <em> <b>Disclaimer</b>. The prototype implementation is experimental
22 > code developed as part of JCP JSR-166 is made available to the
23 > developer community for use as-is. It is not a supported product. Use
24 > it at your own risk. The specification, language and implementation
25 > are subject to change as a result of your feedback. Because these
26 > features have not yet been approved for addition to the Java language,
27 > there is no schedule for their inclusion in a product.  </em>
28 >
29 > <p> <em> <b>Disclaimer</b>.  This draft specification was produced
30 > using JDK1.4 tools plus some preprocessing. The resulting javadocs do
31 > not yet correctly render other planned JDK1.5 constructs on which
32 > JSR-166 relies, most notably the use of generic types. We are
33 > releasing this version now (before the availability of JDK1.5-based
34 > tools) because, even though they are misformatted and sometimes lack
35 > proper cross-referencing, they otherwise convey the intended
36 > specifications.  </em>
37 >
38 > <p> JSR-166 introduces package <tt>java.util.concurrent</tt>
39 > containing utility classes commonly useful in concurrent
40 > programming. Like package <tt>java.util</tt>, it includes a few small
41 > standardized extensible frameworks, as well as some classes that
42 > provide useful functionality and are otherwise tedious or difficult to
43 > implement.
44 >
45 > <p>JSR-166 focusses on breadth, providing critical functionality
46 > useful across a wide range of concurrent programming styles and
47 > applications, ranging from low-level atomic operations, to
48 > customizable locks and synchronization aids, to various concurrent
49 > data structures, to high-level execution agents including thread
50 > pools. This diversity reflects the range of contexts in which
51 > developers of concurrent programs have been found to require or desire
52 > support not previously available in J2SE, which also keeping the
53 > resulting package small; providing only that minimial support for
54 > which it makes sense to standardize.
55 >
56 > <p>Descriptions and brief motivations for the main components may be
57 > found in the associated package documentation.  JSR-166 also includes
58 > a few changes and additions in packages outside of
59 > java.util.concurrent.  Here are brief descriptions.
60  
61   <h2>Queues</h2>
62  
63   A basic (nonblocking) {@link java.util.Queue} interface extending
64 < java.util.Collection is introduced into java.util. Existing class
65 < java.util.LinkedList is adapted to support Queue, and a new
66 < non-thread-safe {@link java.util.concurrent.java.util.PriorityQueue}
67 < is added.  The java.util.concurrent {@link
68 < java.util.concurrent.LinkedQueue} class supplies an efficient
69 < thread-safe non-blocking queue.
70 <
71 < <p> Five implementations in java.util.concurrent support the extended
72 < {@link java.util.concurrent.BlockingQueue} interface, that defines
73 < blocking versions of put and take: {@link
74 < java.util.concurrent.LinkedBlockingQueue}, {@link
75 < java.util.concurrent.ArrayBlockingQueue}, {@link
76 < java.util.concurrent.SynchronousQueue}, {@link
77 < java.util.concurrent.PriorityBlockingQueue}, and {@link DelayQueue}.
78 <
79 <
80 < <h2>Locks</h2>
81 <
82 < The {@link java.util.concurrent.Lock} interface supports locking
83 < disciplines that differ in semantics (reentrant, fair, etc), and that
84 < can be used in non-block-structured contexts including hand-over-hand
92 < and lock reordering algorithms. This flexibility comes at the price of
93 < more awkward syntax.  Implementations include {@link
94 < java.util.concurrent.ReentrantLock} and {@link
95 < java.util.concurrent.FairReentrantLock}.
96 <
97 < <p> The {@link java.util.concurrent.Locks} class additionally supports
98 < some common trylock-designs using builtin locks.
99 <
100 < <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly
101 < defines locks that may be shared among readers but are exclusive to
102 < writers.  Only a single implementation, {@link
103 < java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
104 < covers all standard usage contexts. But programmers may create their
105 < own implementations to cover nonstandard requirements.
106 <
107 < <h2>Conditions</h2>
108 <
109 < The {@link java.util.concurrent.Condition} interface describes the
110 < kinds of condition variables associated with monitors in other
111 < concurrent languages, as well as pthreads-style condvars.  Their
112 < support reduces the need for tricky and/or inefficient solutions to
113 < many classic concurrent problems.  To avoid compatibility problems,
114 < the names of Condition methods are different than Object versions.
115 <
116 < <h2>Atomics</h2>
117 <
118 < The atomic subpackage includes a small library of classes, including
119 < AtomicInteger, AtomicLong, and AtomicReference that support
120 < compareAndSet (CAS) and related atomic operations.
64 > {@link java.util.Collection} is introduced into
65 > <tt>java.util</tt>. Existing class {@link java.util.LinkedList} is
66 > adapted to support Queue, and a new non-thread-safe {@link
67 > java.util.PriorityQueue} is added.
68 >
69 > <h2>Threads</h2>
70 >
71 > Two minor changes are introduced to the {@link java.lang.Thread}
72 > class: It now allows per-thread installation of handlers for uncaught
73 > exceptions. Ths optionally disassociates handlers from ThreadGroups,
74 > which has proven to be too inflexible. (Note that the combination of
75 > features in JSR-166 make ThreadGroups even less likely to be used in
76 > most programs. Perhaps they will eventually be deprecated.) Secondly,
77 > access checks are no longer required when a Thread interrupts
78 > <em>itself</em>.  The <tt>interrupt</tt> method is the only way to
79 > re-assert a thread's interruption status (and in the case of
80 > self-interruption has no other effect than this).  The check here
81 > previously caused unjustifiable and uncontrollable failures when
82 > restricted code invoked library code that must reassert interruption
83 > to correctly propagate status when encountering some
84 > <tt>InterruptedExceptions</tt>.
85  
86   <h2>Timing</h2>
87  
88 < The {@link java.util.concurrent.TimeUnit} class provides multiple
89 < granularities (including nanoseconds) for both accessing time and
90 < performing time-out based operations.
91 <
92 < <h2>Synchronizers</h2>
129 <
130 < Five classes aid common special-purpose synchronization idioms.
131 < {@link java.util.concurrent.Semaphore} and {@link
132 < java.util.concurrent.FairSemaphore} are classic concurrency tools.
133 < {@link java.util.concurrent.CountDownLatch} is very simple yet very
134 < common utility for blocking until a single signal, event, or condition
135 < holds.  A {@link CyclicBarrier} is a resettable multiway
136 < synchronization point common in some styles of parallel
137 < programming. An {@link java.util.concurrent.Exchanger} allows two
138 < threads to exchange objects at a rendezvous point.
139 <
140 < <h2>Concurrent Collections</h2>
141 <
142 < This package supplies a few Collection implementations designed for
143 < use in multithreaded contexts: {@link
144 < java.util.concurrent.ConcurrentHashMap}, {@link
145 < java.util.concurrent.CopyOnWriteArrayList}, and {@link
146 < java.util.concurrent.CopyOnWriteArraySet}.
147 <
148 < <p> Most concurrent Collection implementations (including most Queues)
149 < differ from the usual java.util conventions in that their Iterators
150 < provide <em>weakly consistent</em> rather than fast-fail traversal. A
151 < weakly consistent iterator is thread-safe, but does not necessarily
152 < freeze the collection while iterating, so it may (or may not) reflect
153 < any updates since the iterator was created.
154 <
155 < <h2>Uncaught Exception Handlers</h2>
156 <
157 < The java.lang.Thread class is modified to allow per-thread
158 < installation of handlers for uncaught exceptions. Ths optionally
159 < disassociates these handlers from ThreadGroups, which has proven to be
160 < too inflexible in many multithreaded programs. (Note that the
161 < combination of features in JSR166 make ThreadGroups even less likely
162 < to be used in most programs. Perhaps they will eventually be
163 < deprecated.)
88 > Method <tt>nanoTime</tt> is added to {@link java.lang.System}. It
89 > provides a high-precision timing facility that is distinct from and
90 > uncoordinated with <tt>System.currentTimeMillis</tt>.
91 >
92 > <h2>Removing ThreadLocals</h2>
93  
94 < <p> Additionally, java.lang.ThreadLocal now supports a means to remove
94 > The {@link java.lang.ThreadLocal} class now supports a means to remove
95   a ThreadLocal, which is needed in some thread-pool and worker-thread
96   designs.
97  
98 +
99 +
100    <hr>
101    <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
102   </body>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines