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.19 by dl, Sun Nov 21 01:40:32 2004 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.
13 > This is maintenance repository of JSR166 specifications.  For further
14 > information, go to: <A
15 > HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
16 > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>.
17 >
18 > <p><em>Note: The javadocs here do <em>not</em> include pre-existing
19 > java classes (for example <tt>java.lang.Thread</tt>) that were changed
20 > as part of the JSR166 spec.  On the other hand, the javadocs here so
21 > include some existing java.util Collection interfaces and classes that
22 > are not part of the spec, but are included because some new methods
23 > implement or inherit from their specifications.
24   </em>
25  
26 < <p> Package java.util.concurrent contains utility classes commonly
27 < useful in concurrent programming. Like package java.util, it includes
28 < a few small standardized extensible frameworks, as well as some
29 < classes that provide useful functionality and are otherwise tedious or
30 < difficult to implement.  JSR166 also includes a few changes and
31 < additions in packages outside of java.util.concurrent: java.lang, to
32 < address uncaught exceptions, and java.util to better integrate with
33 < collections.  Since the target release is JDK1.5, many APIs use
34 < generics to parameterize on types.  Here are brief descriptions of the
35 < main components.
36 <
37 < <h2>Executors</h2>
38 <
39 < {@link java.util.concurrent.Executor} is a simple standardized
40 < interface for defining custom thread-like subsystems, including thread
41 < pools, asynch-IO, and lightweight task frameworks.  Depending on which
42 < concrete Executor class is being used, tasks may execute in a newly
43 < created thread, an existing task-execution thread, or the thread
44 < calling <tt>execute()</tt>, and may execute sequentially or
45 < concurrently.  Executors also standardize ways of calling threads that
46 < compute functions returning results, via a {@link
47 < 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 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.
26 > <p> JSR-166 introduces package <tt>java.util.concurrent</tt>
27 > containing utility classes commonly useful in concurrent
28 > programming. Like package <tt>java.util</tt>, it includes a few small
29 > standardized extensible frameworks, as well as other classes that
30 > provide useful functionality and are otherwise tedious or difficult to
31 > implement.
32 >
33 > <p>JSR-166 focusses on breadth, providing critical functionality
34 > useful across a wide range of concurrent programming styles and
35 > applications, ranging from low-level atomic operations, to
36 > customizable locks and synchronization aids, to various concurrent
37 > data structures, to high-level execution agents including thread
38 > pools. This diversity reflects the range of contexts in which
39 > developers of concurrent programs have been found to require or desire
40 > support not previously available in J2SE, which also keeping the
41 > resulting package small; providing only functionality that has been
42 > found to be worthwhile to standardize.
43 >
44 > <p>Descriptions and brief motivations for the main components may be
45 > found in the associated package documentation.  JSR-166 also includes
46 > a few changes and additions in packages outside of
47 > java.util.concurrent.  Here are brief descriptions.
48  
49   <h2>Queues</h2>
50  
51   A basic (nonblocking) {@link java.util.Queue} interface extending
52 < java.util.Collection is introduced into java.util. Existing class
53 < java.util.LinkedList is adapted to support Queue, and a new
54 < non-thread-safe {@link java.util.PriorityQueue}
55 < is added.  The java.util.concurrent {@link
56 < java.util.concurrent.LinkedQueue} class supplies an efficient
57 < thread-safe non-blocking queue.
58 <
59 < <p> Five implementations in java.util.concurrent support the extended
60 < {@link java.util.concurrent.BlockingQueue} interface, that defines
61 < blocking versions of put and take: {@link
62 < java.util.concurrent.LinkedBlockingQueue}, {@link
63 < java.util.concurrent.ArrayBlockingQueue}, {@link
64 < java.util.concurrent.SynchronousQueue}, {@link
65 < java.util.concurrent.PriorityBlockingQueue}, and
66 < {@link java.util.concurrent.DelayQueue}.
67 <
68 <
69 < <h2>Locks</h2>
70 <
71 < The {@link java.util.concurrent.Lock} interface supports locking
72 < disciplines that differ in semantics (reentrant, fair, etc), and that
73 < can be used in non-block-structured contexts including hand-over-hand
74 < and lock reordering algorithms. This flexibility comes at the price of
75 < more awkward syntax.  Implementations include {@link
76 < java.util.concurrent.ReentrantLock} and {@link
77 < java.util.concurrent.FairReentrantLock}.
78 <
79 < <p> The {@link java.util.concurrent.Locks} class additionally supports
80 < 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.
52 > {@link java.util.Collection} is introduced into
53 > <tt>java.util</tt>. Existing class {@link java.util.LinkedList} is
54 > adapted to support Queue, and a new non-thread-safe {@link
55 > java.util.PriorityQueue} is added.
56 >
57 > <h2>Threads</h2>
58 >
59 > Three minor changes are introduced to the {@link java.lang.Thread}
60 > class:
61 > <ul>
62 >  <li> It now allows per-thread installation of handlers for uncaught
63 >  exceptions. Ths optionally disassociates handlers from ThreadGroups,
64 >  which has proven to be too inflexible. (Note that the combination of
65 >  features in JSR-166 make ThreadGroups even less likely to be used in
66 >  most programs. Perhaps they will eventually be deprecated.)
67 >
68 >  <li> Access checks are no longer required when a Thread interrupts
69 >  <em>itself</em>.  The <tt>interrupt</tt> method is the only way to
70 >  re-assert a thread's interruption status (and in the case of
71 >  self-interruption has no other effect than this).  The check here
72 >  previously caused unjustifiable and uncontrollable failures when
73 >  restricted code invoked library code that must reassert interruption
74 >  to correctly propagate status when encountering some
75 >  <tt>InterruptedExceptions</tt>.
76 >  <li> The <tt>destroy</tt> method, which has never been implemented,
77 >  has finally been deprecated. This is just a spec change, reflecting
78 >  the fact that that the reason it has never been implemented is that
79 >  it was undesirable and unworkable.
80 > </ul>
81  
82   <h2>Timing</h2>
83  
84 < The {@link java.util.concurrent.TimeUnit} class provides multiple
85 < granularities (including nanoseconds) for both accessing time and
86 < performing time-out based operations.
87 <
88 < <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.)
84 > Method <tt>nanoTime</tt> is added to {@link java.lang.System}. It
85 > provides a high-precision timing facility that is distinct from and
86 > uncoordinated with <tt>System.currentTimeMillis</tt>.
87 >
88 > <h2>Removing ThreadLocals</h2>
89  
90 < <p> Additionally, java.lang.ThreadLocal now supports a means to remove
90 > The {@link java.lang.ThreadLocal} class now supports a means to remove
91   a ThreadLocal, which is needed in some thread-pool and worker-thread
92   designs.
93  
94 +
95 +
96    <hr>
172  <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
97   </body>
98   </html>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines