From e1bea0c0687c5f4551b3a6058ec37ce3705fa6cc Mon Sep 17 00:00:00 2001 From: Matthias Klose Date: Sun, 3 Jun 2007 23:18:43 +0000 Subject: libjava/classpath/ChangeLog.gcj: 2007-05-31 Matthias Klose * javax/management/NotificationBroadcasterSupport.java (getNotificationInfo): Add cast. * native/jni/qt-peer/Makefile.am (AM_CXXFLAGS): Add libstdc++ include directories. * native/jni/qt-peer/Makefile.in: Regenerate. libjava/ChangeLog: 2007-06-03 Matthias Klose * java/io/natFileWin32.cc (setFilePermissions): New (stub only). _access: Handle EXEC query, stub only. 2007-06-03 Matthias Klose Merged from classpath: * gnu/java/nio/SelectorProviderImpl.java: Whitespace merge. * java/lang/System.java(inheritedChannel): New. * java/lang/Character.java: Remove stray`;'. * java/net/MulticastSocket.java: Merged. * java/text/DateFormatSymbols.java(getInstance): New, comment updates. * java/text/Collator.java(getInstance): Merged. * java/util/Calendar.java: New attributes ALL_STYLES, SHORT, LONG. getDisplayName, getDisplayNames: New. * java/util/logging/Logger.java: Merged. * Regenerate .class and .h files. 2007-06-03 Matthias Klose * java/io/File.java: Merge with classpath-0.95, new method setFilePermissions, new attribute EXEC. * java/io/natFilePosix.cc (setFilePermissions): New. _access: Handle EXEC query. * classpath/lib/java/io/File.class, java/io/File.h: Regenerate. 2007-06-03 Matthias Klose Imported GNU Classpath 0.95. * classpath/Makefile.in, classpath/native/jni/midi-dssi/Makefile.in, classpath/native/jni/classpath/Makefile.in, classpath/native/jni/Makefile.in, classpath/native/jni/gconf-peer/Makefile.in, classpath/native/jni/java-io/Makefile.in, classpath/native/jni/native-lib/Makefile.in, classpath/native/jni/java-util/Makefile.in, classpath/native/jni/midi-alsa/Makefile.in, classpath/native/jni/java-lang/Makefile.in, classpath/native/jni/java-nio/Makefile.in, classpath/native/jni/java-net/Makefile.in, classpath/native/jni/xmlj/Makefile.in, classpath/native/jni/qt-peer/Makefile.in, classpath/native/jni/gtk-peer/Makefile.in, classpath/native/Makefile.in, classpath/native/jawt/Makefile.in, classpath/native/fdlibm/Makefile.in, classpath/native/plugin/Makefile.in, classpath/resource/Makefile.in, classpath/scripts/Makefile.in, classpath/tools/Makefile.in, classpath/doc/Makefile.in, classpath/doc/api/Makefile.in, classpath/lib/Makefile.in, classpath/external/Makefile.in, classpath/external/jsr166/Makefile.in, classpath/external/sax/Makefile.in, classpath/external/w3c_dom/Makefile.in, classpath/external/relaxngDatatype/Makefile.in, classpath/include/Makefile.in, classpath/examples/Makefile.in: Regenerate. * classpath/config.guess, classpath/config.sub, classpath/ltmain.sh : Update. * classpath/configure, classpath/depcomp, classpath/missing, classpath/aclocal.m4, classpath/install-sh: Regenerate. * gnu/classpath/Configuration.java (CLASSPATH_VERSION): Now 0.95. * sources.am: Regenerate. * Makefile.in: Regenerate. * Update the .class files and generated CNI header files, add new .class and generated CNI header files. * Remove generated files for removed java source files: classpath/gnu/java/net/BASE64.java, classpath/gnu/java/security/util/Base64.java, classpath/gnu/java/awt/peer/gtk/GThreadMutex.java, classpath/gnu/java/awt/peer/gtk/GThreadNativeMethodRunner.java, classpath/gnu/java/awt/font/autofit/Scaler.java, classpath/gnu/classpath/jdwp/util/Value.java, classpath/gnu/javax/net/ssl/Base64.java. * Remove empty directories. * Makefile.am(nat_source_files): Add natVMOperatingSystemMXBeanImpl.cc. * java/lang/Class.java(setAccessible): Merge from classpath. * java/util/Locale.java: Remove. * gnu/java/lang/management/VMOperatingSystemMXBeanImpl.java, gnu/java/lang/management/natVMOperatingSystemMXBeanImpl.cc: New. * gcj/javaprims.h: Update class declarations. * scripts/classes.pl: Update usage. * HACKING: Mention to build all peers. From-SVN: r125302 --- .../util/concurrent/ConcurrentSkipListMap.java | 2 +- .../java/util/concurrent/atomic/package.html | 158 --------------- .../jsr166/java/util/concurrent/locks/package.html | 50 ----- .../jsr166/java/util/concurrent/package.html | 222 --------------------- 4 files changed, 1 insertion(+), 431 deletions(-) delete mode 100644 libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html delete mode 100644 libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html delete mode 100644 libjava/classpath/external/jsr166/java/util/concurrent/package.html (limited to 'libjava/classpath/external/jsr166/java/util') diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java b/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java index 52cd17a..bbb00a0 100644 --- a/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java +++ b/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentSkipListMap.java @@ -866,7 +866,7 @@ public class ConcurrentSkipListMap extends AbstractMap if (n != null) { Node f = n.next; if (n != b.next) // inconsistent read - break;; + break; Object v = n.value; if (v == null) { // n is deleted n.helpDelete(b, f); diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html deleted file mode 100644 index 6bc191d..0000000 --- a/libjava/classpath/external/jsr166/java/util/concurrent/atomic/package.html +++ /dev/null @@ -1,158 +0,0 @@ - - -Atomics - - - - -A small toolkit of classes that support lock-free thread-safe -programming on single variables. In essence, the classes in this -package extend the notion of volatile values, fields, and -array elements to those that also provide an atomic conditional update -operation of the form: - -
-  boolean compareAndSet(expectedValue, updateValue);
-
- -

This method (which varies in argument types across different -classes) atomically sets a variable to the updateValue if it -currently holds the expectedValue, reporting true on -success. The classes in this package also contain methods to get and -unconditionally set values, as well as a weaker conditional atomic -update operation weakCompareAndSet desribed below. - -

The specifications of these methods enable implementations to -employ efficient machine-level atomic instructions that are available -on contemporary processors. However on some platforms, support may -entail some form of internal locking. Thus the methods are not -strictly guaranteed to be non-blocking -- -a thread may block transiently before performing the operation. - -

Instances of classes {@link -java.util.concurrent.atomic.AtomicBoolean}, {@link -java.util.concurrent.atomic.AtomicInteger}, {@link -java.util.concurrent.atomic.AtomicLong}, and {@link -java.util.concurrent.atomic.AtomicReference} each provide access and -updates to a single variable of the corresponding type. Each class -also provides appropriate utility methods for that type. For example, -classes AtomicLong and AtomicInteger provide atomic -increment methods. One application is to generate sequence numbers, -as in: - -

-class Sequencer {
-  private AtomicLong sequenceNumber = new AtomicLong(0);
-  public long next() { return sequenceNumber.getAndIncrement(); }
-}
-
- -

The memory effects for accesses and updates of atomics generally -follow the rules for volatiles, as stated in The Java Language -Specification, Third Edition (17.4 Memory Model): - -

    - -
  • get has the memory effects of reading a -volatile variable. - -
  • set has the memory effects of writing (assigning) a -volatile variable. - -
  • lazySet has the memory effects of writing (assigning) - a volatile variable except that it permits reorderings with - subsequent (but not previous) memory actions that do not themselves - impose reordering constraints with ordinary non-volatile - writes. Among other usage contexts, lazySet may apply when - nulling out, for the sake of garbage collection, a reference that is - never accessed again. - -
  • weakCompareAndSet atomically reads and conditionally - writes a variable but does not - create any happens-before orderings, so provides no guarantees - with respect to previous or subsequent reads and writes of any - variables other than the target of the weakCompareAndSet. - -
  • compareAndSet - and all other read-and-update operations such as getAndIncrement - have the memory effects of both reading and - writing volatile variables. -
- -

In addition to classes representing single values, this package -contains Updater classes that can be used to obtain -compareAndSet operations on any selected volatile -field of any selected class. {@link -java.util.concurrent.atomic.AtomicReferenceFieldUpdater}, {@link -java.util.concurrent.atomic.AtomicIntegerFieldUpdater}, and {@link -java.util.concurrent.atomic.AtomicLongFieldUpdater} are -reflection-based utilities that provide access to the associated field -types. These are mainly of use in atomic data structures in which -several volatile fields of the same node (for example, the -links of a tree node) are independently subject to atomic -updates. These classes enable greater flexibility in how and when to -use atomic updates, at the expense of more awkward reflection-based -setup, less convenient usage, and weaker guarantees. - -

The {@link java.util.concurrent.atomic.AtomicIntegerArray}, {@link -java.util.concurrent.atomic.AtomicLongArray}, and {@link -java.util.concurrent.atomic.AtomicReferenceArray} classes further -extend atomic operation support to arrays of these types. These -classes are also notable in providing volatile access -semantics for their array elements, which is not supported for -ordinary arrays. - -

The atomic classes also support method weakCompareAndSet, -which has limited applicability. On some platforms, the weak version -may be more efficient than compareAndSet in the normal case, -but differs in that any given invocation of weakCompareAndSet -method may return false spuriously (that is, for no apparent -reason). A false return means only that the operation may be -retried if desired, relying on the guarantee that repeated invocation -when the variable holds expectedValue and no other thread is -also attempting to set the variable will eventually succeed. (Such -spurious failures may for example be due to memory contention effects -that are unrelated to whether the expected and current values are -equal.) Additionally weakCompareAndSet does not provide -ordering guarantees that are usually needed for synchronization -control. However, the method may be useful for updating counters and -statistics when such updates are unrelated to the other happens-before -orderings of a program. When a thread sees an update to an atomic -variable caused by a weakCompareAndSet, it does not -necessarily see updates to any other variables that occurred -before the weakCompareAndSet. This may be acceptable when -for example updating performance statistics, but rarely otherwise. - -

The {@link java.util.concurrent.atomic.AtomicMarkableReference} -class associates a single boolean with a reference. For example, this -bit might be used inside a data structure to mean that the object -being referenced has logically been deleted. The {@link -java.util.concurrent.atomic.AtomicStampedReference} class associates -an integer value with a reference. This may be used for example, to -represent version numbers corresponding to series of updates. - -

Atomic classes are designed primarily as building blocks for -implementing non-blocking data structures and related infrastructure -classes. The compareAndSet method is not a general -replacement for locking. It applies only when critical updates for an -object are confined to a single variable. - -

Atomic classes are not general purpose replacements for -java.lang.Integer and related classes. They do not -define methods such as hashCode and -compareTo. (Because atomic variables are expected to be -mutated, they are poor choices for hash table keys.) Additionally, -classes are provided only for those types that are commonly useful in -intended applications. For example, there is no atomic class for -representing byte. In those infrequent cases where you would -like to do so, you can use an AtomicInteger to hold -byte values, and cast appropriately. You can also hold floats -using Float.floatToIntBits and Float.intBitstoFloat -conversions, and doubles using Double.doubleToLongBits and -Double.longBitsToDouble conversions. - - -@since 1.5 - - diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html deleted file mode 100644 index 4b94525..0000000 --- a/libjava/classpath/external/jsr166/java/util/concurrent/locks/package.html +++ /dev/null @@ -1,50 +0,0 @@ - - -Locks - - - - -Interfaces and classes providing a framework for locking and waiting -for conditions that is distinct from built-in synchronization and -monitors. The framework permits much greater flexibility in the use of -locks and conditions, at the expense of more awkward syntax. - -

The {@link java.util.concurrent.locks.Lock} interface supports -locking disciplines that differ in semantics (reentrant, fair, etc), -and that can be used in non-block-structured contexts including -hand-over-hand and lock reordering algorithms. The main implementation -is {@link java.util.concurrent.locks.ReentrantLock}. - -

The {@link java.util.concurrent.locks.ReadWriteLock} interface -similarly defines locks that may be shared among readers but are -exclusive to writers. Only a single implementation, {@link -java.util.concurrent.locks.ReentrantReadWriteLock}, is provided, since -it covers most standard usage contexts. But programmers may create -their own implementations to cover nonstandard requirements. - -

The {@link java.util.concurrent.locks.Condition} interface -describes condition variables that may be associated with Locks. -These are similar in usage to the implicit monitors accessed using -Object.wait, but offer extended capabilities. In particular, -multiple Condition objects may be associated with a single -Lock. To avoid compatibility issues, the names of -Condition methods are different than the corresponding -Object versions. - -

The {@link java.util.concurrent.locks.AbstractQueuedSynchronizer} -class serves as a useful superclass for defining locks and other -synchronizers that rely on queuing blocked threads. The {@link -java.util.concurrent.locks.AbstractQueuedLongSynchronizer} class -provides the same functionality but extends support to 64 bits of -synchronization state. Both extend class {@link -java.util.concurrent.locks.AbstractOwnableSynchronizer}, a simple -class that helps record the thread currently holding exclusive -synchronization. The {@link java.util.concurrent.locks.LockSupport} -class provides lower-level blocking and unblocking support that is -useful for those developers implementing their own customized lock -classes. - -@since 1.5 - - diff --git a/libjava/classpath/external/jsr166/java/util/concurrent/package.html b/libjava/classpath/external/jsr166/java/util/concurrent/package.html deleted file mode 100644 index 20227e1f..0000000 --- a/libjava/classpath/external/jsr166/java/util/concurrent/package.html +++ /dev/null @@ -1,222 +0,0 @@ - - -Concurrency Utilities - - - - -

Utility classes commonly useful in concurrent programming. This -package includes a few small standardized extensible frameworks, as -well as some classes that provide useful functionality and are -otherwise tedious or difficult to implement. Here are brief -descriptions of the main components. See also the locks and -atomic packages. - -

Executors

- -Interfaces. {@link java.util.concurrent.Executor} is a simple -standardized interface for defining custom thread-like subsystems, -including thread pools, asynchronous IO, and lightweight task -frameworks. Depending on which concrete Executor class is being used, -tasks may execute in a newly created thread, an existing -task-execution thread, or the thread calling execute(), and -may execute sequentially or concurrently. {@link -java.util.concurrent.ExecutorService} provides a more complete -asynchronous task execution framework. An ExecutorService manages -queuing and scheduling of tasks, and allows controlled shutdown. The -{@link java.util.concurrent.ScheduledExecutorService} subinterface -and associated interfaces add support for delayed and periodic task execution. -ExecutorServices provide methods arranging asynchronous execution of -any function expressed as {@link java.util.concurrent.Callable}, the -result-bearing analog of {@link java.lang.Runnable}. A {@link -java.util.concurrent.Future} returns the results of a function, allows -determination of whether execution has completed, and provides a means to -cancel execution. A {@link java.util.concurrent.RunnableFuture} is -a Future that possesses a run method that upon execution, -sets its results. - -

- -Implementations. Classes {@link -java.util.concurrent.ThreadPoolExecutor} and {@link -java.util.concurrent.ScheduledThreadPoolExecutor} provide tunable, -flexible thread pools. The {@link java.util.concurrent.Executors} -class provides factory methods for the most common kinds and -configurations of Executors, as well as a few utility methods for -using them. Other utilities based on Executors include the concrete -class {@link java.util.concurrent.FutureTask} providing a common -extensible implementation of Futures, and {@link -java.util.concurrent.ExecutorCompletionService}, that assists in -coordinating the processing of groups of asynchronous tasks. - -

Queues

- -The java.util.concurrent {@link -java.util.concurrent.ConcurrentLinkedQueue} class supplies an -efficient scalable thread-safe non-blocking FIFO queue. Five -implementations in java.util.concurrent support the extended {@link -java.util.concurrent.BlockingQueue} interface, that defines blocking -versions of put and take: {@link -java.util.concurrent.LinkedBlockingQueue}, {@link -java.util.concurrent.ArrayBlockingQueue}, {@link -java.util.concurrent.SynchronousQueue}, {@link -java.util.concurrent.PriorityBlockingQueue}, and {@link -java.util.concurrent.DelayQueue}. The different classes cover the most -common usage contexts for producer-consumer, messaging, parallel -tasking, and related concurrent designs. The {@link -java.util.concurrent.BlockingDeque} interface extends -BlockingQueue to support both FIFO and LIFO (stack-based) -operations. Class {@link java.util.concurrent.LinkedBlockingDeque} -provides an implementation. - - -

Timing

- -The {@link java.util.concurrent.TimeUnit} class provides multiple -granularities (including nanoseconds) for specifying and controlling -time-out based operations. Most classes in the package contain -operations based on time-outs in addition to indefinite waits. In all -cases that time-outs are used, the time-out specifies the minimum time -that the method should wait before indicating that it -timed-out. Implementations make a "best effort" to detect -time-outs as soon as possible after they occur. However, an indefinite -amount of time may elapse between a time-out being detected and a -thread actually executing again after that time-out. All methods -that accept timeout parameters treat values less than or equal to -zero to mean not to wait at all. To wait "forever", you can use -a value of Long.MAX_VALUE. - -

Synchronizers

- -Four classes aid common special-purpose synchronization idioms. -{@link java.util.concurrent.Semaphore} is a classic concurrency tool. -{@link java.util.concurrent.CountDownLatch} is a very simple yet very -common utility for blocking until a given number of signals, events, -or conditions hold. A {@link java.util.concurrent.CyclicBarrier} is a -resettable multiway synchronization point useful in some styles of -parallel programming. An {@link java.util.concurrent.Exchanger} allows -two threads to exchange objects at a rendezvous point, and is useful -in several pipeline designs. - -

Concurrent Collections

- -Besides Queues, this package supplies Collection implementations -designed for use in multithreaded contexts: -{@link java.util.concurrent.ConcurrentHashMap}, -{@link java.util.concurrent.ConcurrentSkipListMap}, -{@link java.util.concurrent.ConcurrentSkipListSet}, -{@link java.util.concurrent.CopyOnWriteArrayList}, and -{@link java.util.concurrent.CopyOnWriteArraySet}. -When many threads are expected to access a given collection, -a ConcurrentHashMap is normally preferable to -a synchronized HashMap, and a -ConcurrentSkipListMap is normally preferable -to a synchronized TreeMap. A -CopyOnWriteArrayList is preferable to -a synchronized ArrayList when the expected number of reads -and traversals greatly outnumber the number of updates to a list. - -

The "Concurrent" prefix used with some classes in this package is a -shorthand indicating several differences from similar "synchronized" -classes. For example java.util.Hashtable and -Collections.synchronizedMap(new HashMap()) are -synchronized. But {@link java.util.concurrent.ConcurrentHashMap} is -"concurrent". A concurrent collection is thread-safe, but not -governed by a single exclusion lock. In the particular case of -ConcurrentHashMap, it safely permits any number of concurrent reads as -well as a tunable number of concurrent writes. "Synchronized" classes -can be useful when you need to prevent all access to a collection via -a single lock, at the expense of poorer scalability. In other cases in -which multiple threads are expected to access a common collection, -"concurrent" versions are normally preferable. And unsynchronized -collections are preferable when either collections are unshared, or -are accessible only when holding other locks. - -

Most concurrent Collection implementations (including most Queues) -also differ from the usual java.util conventions in that their Iterators -provide weakly consistent rather than fast-fail traversal. A -weakly consistent iterator is thread-safe, but does not necessarily -freeze the collection while iterating, so it may (or may not) reflect -any updates since the iterator was created. - - -

Memory Consistency Properties

- - -Chapter 17 of the Java Language Specification defines the -happens-before relation on memory operations such as reads and -writes of shared variables. The results of a write by one thread are -guaranteed to be visible to a read by another thread only if the write -operation happens-before the read operation. The -{@code synchronized} and {@code volatile} constructs, as well as the -{@code Thread.start()} and {@code Thread.join()} methods, can form -happens-before relationships. In particular: - -
    -
  • Each action in a thread happens-before every action in that - thread that comes later in the program's order. - -
  • An unlock ({@code synchronized} block or method exit) of a - monitor happens-before every subsequent lock ({@code synchronized} - block or method entry) of that same monitor. And because - the happens-before relation is transitive, all actions - of a thread prior to unlocking happen-before all actions - subsequent to any thread locking that monitor. - -
  • A write to a {@code volatile} field happens-before every - subsequent read of that same field. Writes and reads of - {@code volatile} fields have similar memory consistency effects - as entering and exiting monitors, but do not entail - mutual exclusion locking. - -
  • A call to {@code start} on a thread happens-before any action in the - started thread. - -
  • All actions in a thread happen-before any other thread - successfully returns from a {@code join} on that thread. - -
- - -The methods of all classes in {@code java.util.concurrent} and its -subpackages extend these guarantees to higher-level -synchronization. In particular: - -
    - -
  • Actions in a thread prior to placing an object into any concurrent - collection happen-before actions subsequent to the access or - removal of that element from the collection in another thread. - -
  • Actions in a thread prior to the submission of a {@code Runnable} - to an {@code Executor} happen-before its execution begins. - Similarly for {@code Callables} submitted to an {@code ExecutorService}. - -
  • Actions taken by the asynchronous computation represented by a - {@code Future} happen-before actions subsequent to the - retrieval of the result via {@code Future.get()} in another thread. - -
  • Actions prior to "releasing" synchronizer methods such as - {@code Lock.unlock}, {@code Semaphore.release}, and - {@code CountDownLatch.countDown} happen-before actions - subsequent to a successful "acquiring" method such as - {@code Lock.lock}, {@code Semaphore.acquire}, - {@code Condition.await}, and {@code CountDownLatch.await} on the - same synchronizer object in another thread. - -
  • For each pair of threads that successfully exchange objects via - an {@code Exchanger}, actions prior to the {@code exchange()} - in each thread happen-before those subsequent to the - corresponding {@code exchange()} in another thread. - -
  • Actions prior to calling {@code CyclicBarrier.await} - happen-before actions performed by the barrier action, and - actions performed by the barrier action happen-before actions - subsequent to a successful return from the corresponding {@code await} - in other threads. - -
- -@since 1.5 - - -- cgit v1.1