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.5 by dholmes, Thu Jun 26 04:56:11 2003 UTC vs.
Revision 1.10 by tim, Wed Aug 6 16:04:58 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 Community Review Draft Introduction.</title>
5    </head>
6  
7    <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8 <  <h1>JSR 166 Snapshot Introduction.</h1>
8 >  <h1>JSR 166 Community Review Draft 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 <
13 > To chack for updates to this draft, access a preliminary prototype
14 > release of main functionality, or join a mailing list discussing this
15 > JSR, go to: <A
16 > HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
17 > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
18 > .
19   <p>
20 < <em>
21 < Disclaimer - This prototype is experimental code developed as part of
22 < JCP JSR166 and made available to the developer community for use
23 < as-is. It is not a supported product. Use it at your own risk. The
24 < specification, language and implementation are subject to change as a
25 < result of your feedback. Because these features have not yet been
26 < approved for addition to the Java language, there is no schedule for
27 < their inclusion in a product.
28 < </em>
29 <
30 < <p> Package java.util.concurrent contains utility classes commonly
31 < useful in concurrent programming. Like package java.util, it includes
32 < a few small standardized extensible frameworks, as well as some
33 < classes that provide useful functionality and are otherwise tedious or
34 < difficult to implement.  JSR166 also includes a few changes and
35 < additions in packages outside of java.util.concurrent: java.lang, to
36 < address uncaught exceptions, and java.util to better integrate with
37 < collections.  Since the target release is JDK1.5, many APIs use
38 < generics to parameterize on types.  Here are brief descriptions of the
39 < main components.
40 <
41 < <h2>Executors</h2>
42 <
43 < {@link java.util.concurrent.Executor} is a simple standardized
44 < interface for defining custom thread-like subsystems, including thread
45 < pools, asynch-IO, and lightweight task frameworks.  Depending on which
46 < concrete Executor class is being used, tasks may execute in a newly
47 < created thread, an existing task-execution thread, or the thread
48 < calling <tt>execute()</tt>, and may execute sequentially or
49 < concurrently.  Executors also standardize ways of calling threads that
50 < compute functions returning results, via a {@link
51 < java.util.concurrent.Future}. This is supported in part by defining
52 < interface {@link java.util.concurrent.Callable}, the argument/result
53 < analog of Runnable.
54 <
55 < <p> {@link java.util.concurrent.ExecutorService} provides a more
56 < complete framework for executing Runnables.  An ExecutorService
57 < manages queueing and scheduling of tasks, and allows controlled
58 < shutdown.  The two primary implementations of ExecutorService are
59 < {@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 java.util.concurrent.FutureTask}
61 < to asynchronously
62 < 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.
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.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
78 < {@link java.util.concurrent.DelayQueue}.
79 <
80 <
81 < <h2>Locks</h2>
82 <
83 < The {@link java.util.concurrent.Lock} interface supports locking
84 < disciplines that differ in semantics (reentrant, fair, etc), and that
93 < can be used in non-block-structured contexts including hand-over-hand
94 < and lock reordering algorithms. This flexibility comes at the price of
95 < more awkward syntax.  Implementations include {@link
96 < java.util.concurrent.ReentrantLock} and {@link
97 < java.util.concurrent.FairReentrantLock}.
98 <
99 < <p> The {@link java.util.concurrent.Locks} class additionally supports
100 < some common trylock-designs using builtin locks.
101 <
102 < <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly
103 < defines locks that may be shared among readers but are exclusive to
104 < writers.  Only a single implementation, {@link
105 < java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
106 < covers all standard usage contexts. But programmers may create their
107 < own implementations to cover nonstandard requirements.
108 <
109 < <h2>Conditions</h2>
110 <
111 < The {@link java.util.concurrent.Condition} interface describes the
112 < kinds of condition variables associated with monitors in other
113 < concurrent languages, as well as pthreads-style condvars.  Their
114 < support reduces the need for tricky and/or inefficient solutions to
115 < many classic concurrent problems.  To avoid compatibility problems,
116 < the names of Condition methods are different than Object versions.
117 <
118 < <h2>Atomics</h2>
119 <
120 < The atomic subpackage includes a small library of classes, including
121 < AtomicInteger, AtomicLong, and AtomicReference that support
122 < 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>
131 <
132 < Five classes aid common special-purpose synchronization idioms.
133 < {@link java.util.concurrent.Semaphore} and {@link
134 < java.util.concurrent.FairSemaphore} are classic concurrency tools.
135 < {@link java.util.concurrent.CountDownLatch} is very simple yet very
136 < common utility for blocking until a single signal, event, or condition
137 < holds.  A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway
138 < synchronization point common in some styles of parallel
139 < programming. An {@link java.util.concurrent.Exchanger} allows two
140 < threads to exchange objects at a rendezvous point.
141 <
142 < <h2>Concurrent Collections</h2>
143 <
144 < This package supplies a few Collection implementations designed for
145 < use in multithreaded contexts: {@link
146 < java.util.concurrent.ConcurrentHashMap}, {@link
147 < java.util.concurrent.CopyOnWriteArrayList}, and {@link
148 < java.util.concurrent.CopyOnWriteArraySet}.
149 <
150 < <p> Most concurrent Collection implementations (including most Queues)
151 < differ from the usual java.util conventions in that their Iterators
152 < provide <em>weakly consistent</em> rather than fast-fail traversal. A
153 < weakly consistent iterator is thread-safe, but does not necessarily
154 < freeze the collection while iterating, so it may (or may not) reflect
155 < any updates since the iterator was created.
156 <
157 < <h2>Uncaught Exception Handlers</h2>
158 <
159 < The java.lang.Thread class is modified to allow per-thread
160 < installation of handlers for uncaught exceptions. Ths optionally
161 < disassociates these handlers from ThreadGroups, which has proven to be
162 < too inflexible in many multithreaded programs. (Note that the
163 < combination of features in JSR166 make ThreadGroups even less likely
164 < to be used in most programs. Perhaps they will eventually be
165 < 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