concurrency and other critical software issues

Google Android contains j.u.c

2007-11-16T16:55:00.000-05:00

Great news: Android.jar contains package java.util.concurrent and sub-packages atomic and locks.

It also contains intriguing org.apache.http.util.concurrent containing classes Executor.java and ThreadFactory.java.

It has of course many more packages. It seems to be more than Java SE, rather than something between Java ME and Java SE. It looks like Google removed a few packages from SE and added their own. For example, they have removed, awt, Swing, corba.

I hope the speech recognition API works.

I also hope that it has better APIs than current Java open source products for accessing peripherals. These shouldn't be too hard to beat, the JCP-issued APIs being so poor at it. Android seems to have a generic way for programs to communicate with the OS and with services running on a device, including peripherals. The Java world really needed this badly (i.e., a way to integrate with peripherals) and we have been promised this by Sun et al. since 1996, but few were delivered. Soon we should know if Google has delivered it, by trying our Android apps in an emulator. But the final proof will be when the devices are out and the carriers/telcos are supporting them, probably in 12 months or so, if we are lucky.

Will we have to move to a different country in order to be able to use some of cool apps on Android, including our own?

Current Approaches As Of August 2007

2007-08-26T13:09:00.000-04:00

The conventional multithreading where the programmer writes all the controls for the threads and how they share and don't share data, in the hope of optimizing resources (e.g., threads, memory, communication).

New multithreading techniques, some usable, some in dev, where the programmer does not have to write all the controls for the threads and how they share and don't share data, and yet resources are still optimized.

The most promising technique is TM - not Transcendental Meditation - but Transactional Memory, where the CPU (instruction set), OS, and VM are designed to make all accesses to the RAM work somewhat like transactional access to a database.
Sun will be including TM in it's Rock processor due near the end of 2008.
X10 - an extension of Java - in development - IBM is a main contributor.

Grid-for-Concurrency frameworks that allow at least some sharing of data between threads:

Fork-Join Frameworks:

The most popular is Google's MapReduce.

TODO - more fork-join examples

The Appistry Grid where the programmer writes single-threaded logic and the underlying system takes care of managing the available resources (threads and memory).
TODO other grid (for concurrency) examples.

Java EE - A great multithreading platform, particularly the EJB containers. The extra seconds in http request processing are worth it when considering the difficulties in developing robust, mission-critical multithreaded apps and the reduction in costs that Java EE makes possible for such apps.

UPDATE 2007.10.13: memory leaks occurring when using a ThreadLocal in certain situations maybe reducing Java EE's advantage for safe multithreading.

Appistry is one way of doing it

2007-03-25T19:57:00.000-04:00

Appistry 3.5

allows Java and .NET applications to scale out across a number of servers while running as though it were one application on one server. The Fabric makes the application think it's running on one computer, and the developer writes applications as though it will run on a single computer. But in execution, the application could be distributed over 100 or more computers.

So we seem to have at least 4 approaches:

The conventional multithreading where the programmer writes all the controls for the threads and how they share and don't share data, in the hope of optimizing resources (e.g., threads, memory, communication).
The future multithreading yet to be usable, where the programmer does not have to write all the controls for the threads and how they share and don't share data, yet resources are still optimized.
The Google Grid technique called MapReduce.
The Appistry Grid technique where the programmer writes single-threaded logic and the underlying system takes care of managing the available resources (threads and memory).

The Appistry approach seems to pose difficulties for applications that require multiple threads to share data. It allows applications to launch multiple threads but probably does not offer more help for controling their interactions than what the language already offers. This remains to be verified. If it is the case, then for scaling, the programmer has to make difficult non-obvious choices between the single-thread auto-scaling by Fabric versus the conventional multithreading approach. I would think that if you have Fabric then you minimize your use of multithreading.

Gosling Agrees: The next big thing is multithreading

2007-03-25T19:50:00.000-04:00

Dr James Gosling on c|net news.com, March 19, 2007: The next big innovation is multithreading.

What do you think will be the next big tech innovation that will affect enterprise IT?
Gosling: There's a lot of stuff going on around multithreading--for example, the way that Moore's Law is shifting from clock rate to number of cores, which means people have to be increasingly conscious of what it means to build multithreaded applications.

Erlang is top contender for distributed app today

2007-03-04T17:31:00.000-05:00

The book on Erlang, by the creator of Erlang, Joe Armstrong.

Joe designed and implemented the first version of Erlang in 1986 and he currently works for Ericsson AB where Erlang is used to build highly-fault tolerant switching systems.

The above link has links to 2 large size pdf extracts from the book. One is http://media.pragprog.com/titles/jaerlang/Concurrent.pdf

The web site on the open source version: http://www.erlang.org/

Here's a 2007.03.03 blog by Tim O'Reilly on Erlang and other concurrency issues.

Tim mentions that some have found Erlang to be too "old".

TODO learn Erlang

Erlang is called "a pure message passing language". Erlang processes do not share memory. It is excellent for distributed apps but can it be considered a standard multithreaded language? I do not yet know if Erlang has threads where memory is shared.

I recommend that we distinguish standard multithreaded languages where threads share memory from those where threads do not share memory.

Dave Patterson, et al., U.C., Berkely

2007-02-11T13:52:00.000-05:00

A web page from Dec. 18, 2006: The Landscape of Parallel Computing Research: A View from Berkeley - Introduces this pdf.

My summary of this paper (they call it white):
• Goal = make it easy to write programs (that execute efficiently on highly parallel systems).
• 1000s of cores per chip.
• For benchmarking, use Dwarfs (a dwarf is a basic class of patterns of computation and communication, a primary type of computation); this team has defined 13 dwarfs currently. For example, MapReduce is a dwarf, Spectral Methods (a type of DSP that includes FFT) is another.
• Use Autotuners to select the most effective implementation of a library, of a dwarf or other pattern, at development or deploy time.
• Programming models to be more human-centric (to help developers with concurrency issues).
• Programming models to be independent of the number of processors where an application is deployed.
• Systems to include performance and energy counters adapted to multicore and for use by developers.

The blog - very useful, I recommend it.

The wiki. I don't know how complete this section is but it is useful start: Parallel Programming Model Watch

The glossary is also useful and necessary to read this wiki.

A discussion on Slashdot. Entries show that many if not most developers have a weak grasp of the issues. There's a lot of work to be done for multicores to be effectively used.

Ms Crawford sells IBM Roadrunner

2007-02-01T19:58:00.000-05:00

Catherine Crawford, cait@alum.mit.edu, chief architect for next-generation systems software at IBM Systems Group's Quasar Design Center, writes here.

"Where's the software to take advantage of all these processors, cores and threads?"

"IDC's Earl Joseph concluded in a study on technical computing software that 'many ISV codes today scale only to 32 processors, and some of the most important ones for industry don't scale beyond four processors' (www.hpcwire.com/hpc/43036§0. html)."

The Roadrunner system from IBM is alledged to enabled easier development of multithreading software but does not provide substancial information. The reader must then google Roadrunner IBM in order to get the marketing material on this new product line. Exactly what IBM wants us to do so that we may come to believe that Roadrunner is a solution, if we read enough about it.

Sun's FORTRESS is now open source

2007-01-21T10:11:00.000-05:00

http://fortress.sunsource.net/

Fortress code is concurrent by default and requires programmers to specify when a code section is not concurrent, which was my thinking also a few months ago.

Summary article here.

Sun has recently lost the continuation for a nice military contract for a new supercomputer architecture to IBM and Cray, and this open sourcing may have something to do with this loss.

Cringely says no apps for multicores in 2007

2007-01-07T13:57:00.000-05:00

One of Cringely's predictions for 2007 involves multi-core chips and the difficulties of multithreading:

"5) AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up."

Unfortunately, he doen't mention ideas for solutions. Nevertheless, realizing that we have a problem would help us towards the solution.

Cringely has not predicted a wave of bugs appearing in old applications when people start using multicore chips. I wonder if he is aware of this possible future type of events.

Transactional Memory - A Contender for The Solution

2006-12-29T10:27:00.000-05:00

This unproven technique is apparently implemented in the announced Azul Systems product (supported by IBM and BAE, and sued by Sun). TM may be a valid solution for many situations for multithreaded apps. Here's a biblio:

http://www.cs.wisc.edu/trans-memory/biblio/index.html

TODO evaluate technology - there are a few recent opinions in the java concurrent mailing list.

Update 2007.01.21: ACM article by Intel and Stanford U. - TODO read carefully

Desktop Java EE Apps Anyone?

2006-12-28T14:06:00.000-05:00

Here's an extract from a post by Bill Shannon, Java EE Spec Lead, on Java EE App Clients. I am evaluating the use of Java EE technology on the desktop to reduce the costs of delivering defect free multithreaded apps. The idea is to try to mostly let the Java EE container manage the threads and no server would be used. It's a complete Java EE on the desktop, standalone (no server). The Java EE container(s), server-side and client-side, would be running on the desktop. In the current Java EE design, the Java EE server-side container still runs on a separate host, but not in my experimental design. One could always have the application start the Java EE server-side container if it needs to when it starts (when the app starts that is).

The main difficulties may be in deployment, e.g., very large jars, the automation of the installation the Java EE container (on the desktop), etc., but these may still be simpler than producing defect free multithreaded apps without Java EE.

It looks like *app clients* are applications running in a Java EE client-side container. The other alternative, of course, is to use a browser for the user interface objects via http to the Java EE code (on the desktop), instead of the Java SE GUI offered by an app client.

Finally, here's the post that I promised:

Re: Java EE appclients vs standalone clients
Posted: Nov 27, 2006 1:40 PM

Apparently there's some confusion over application clients. To quote from the Java EE platform spec:

....Application clients are Java programming language
....programs that are typically GUI programs that execute
....on a desktop computer. Application clients offer a
....user experience similar to that of native applications,
....and have access to all of the facilities of the Java EE
....middle tier.

Application clients are not expected to execute on the server, although some people have found that useful in some situations.

Application clients are simply standalone Java applications that execute in an environment that conveniently provides access to the Java EE facilities. It's the application client container that provides Java EE support to the application client program.

Some people want to run "regular" Java SE applications, but have access to Java EE facilities without need for the application client container. Yes, you can do this. There's no magic here. But there is a lot of work. You can duplicate most or all of the work that the application client container is doing for you, and thus run your "standalone" Java EE client application without using the application client container.

...

What we've done in GlassFish, and what we're considering adding to the specification, is add support for Java Web Start for deploying application clients. This allows the client desktop machine to download the application client program on demand.

Some people want to use their own deployment approaches, automated or manual, for deploying their desktop applications. What they'd like is to have a simple, small jar file or other bundle that is their application client, and run that application just like they would run any other Java SE application. This is the case that drives people to "standalone applications" instead of application clients.

What we should do is create a simpler "application client runtime", as similar as possible to the simple "java" command, that could be used to run these applications.

The final deficiency, and one of the harder problems to solve, is that the application client container depends on the application server fairly heavily, e.g., for configuring access to resources. If the server is unavailable (due to network problems or whatever), the application client has no reasonable way to function in any sort of degraded mode until the server is available again. Improving this definitely requires work in the GlassFish implementation, and may also require changes to the Java EE specification.

Bill Shannon
Java EE Spec Lead

security: extended-validation certificate (EV) and alerts

2006-12-24T15:36:00.000-05:00

http://news.yahoo.com/s/ap/20061224/ap_on_hi_te/internet_padlocks

because security is another critical issue, specially for online businesses.

update: www.certstation.com - an aggregate of 8 alert services

Two big steps for a thread-safe object-based app

2006-12-22T08:51:00.000-05:00

1) Build well-designed thread-safe objects (classes) for the app.

2) Make sure that the objects interact in a thread-safe way in the application.

This was re-stated by Brian Goetz at Javapolis 2006. Brian proposed that the use of an object-oriented language, good object design, and this two-step process, do help minimize the costs of developing a thread-safe application these days.

It's just that both step 1 and 2 are relatively very expensive and often improperly done, which results in defects. The resulting total costs are comparable to and may surpass the costs of using Java EE correctly. It may be that in 2007 and 2008, the least expensive way to develop thread-safe applications is the use of Java EE version 5, possibly even for desktop apps.

TODO look into ways to use Java EE 5 on the desktop, with and without an http-based user interface (e.g., with Swing).

New Java Tool to Test Synchronization Issues: ConTest

2006-12-22T08:43:00.000-05:00

ConcurrentTesting - Advanced Testing for Multi-Threaded Applications

from IBM Alphaworks: http://www.alphaworks.ibm.com/tech/contest

TODO: try and review

Thread-Safety According to Intel

2006-12-17T21:16:00.000-05:00

Advanced:
http://www3.intel.com/cd/ids/developer/asmo-na/eng/327695.htm

Beginner:
http://www3.intel.com/cd/ids/developer/asmo-na/eng/327681.htm

Update 2007.01.04:
http://www3.intel.com/cd/ids/developer/asmo-na/eng/219575.htm

Is FORTRESS an Improvement over Java?

2006-12-09T10:27:00.000-05:00

Guy Steele describes his FORTRESS programming language as an improvement over FORTRAN and seems to imply that is equivalent to Java, but is it?

Steele has been quoted as saying "FORTRESS is to FORTRAN what Java is to C/C++". But if FORTRESS is as generic as it also has been described and if it is as good at easing the pains of developing concurrent applications as some claim (Hal Stern and James Gosling for example), then it may be worth considering as a replacement for Java also, and not just for FORTRAN?

Sun's CoolThread, Niagara, and the Rock

2006-12-09T10:26:00.000-05:00

T1, T2000, etc.

http://www.theinquirer.net/default.aspx?article=36247

TODO summary here

New Azul Multicore Systems for Java

2006-12-09T10:24:00.000-05:00

Note that Sun is suing Azul for patent infrigments.
http://www.theinquirer.net/default.aspx?article=31461

TODO more here on the new Azul systems

JSR 121 App Isolation API is not the solution

2006-11-29T19:38:00.000-05:00

JSR 121 Application Isolation API may be a good solution for some problems but not for the easier concurrent programming one.

http://jcp.org/en/jsr/detail?id=121

A recent post about JSR 121.

Gradual steps or paradigm shift towards easier concurrent apps?

2006-11-25T07:46:00.000-05:00

Herb Sutter's distinguishing argument is for a gradual evolution of programming languages and techniques (IDEs, APIs) towards easier concurrent program development.

My take on this is that we can only do gradual evolution right now because we don't really know how to do easy concurrent programs, i.e., we don't have an adequate programming language yet, but gradual is not sufficient (because still too difficult) and we will need a completely different language, asap.

Gradual steps may take us there eventually but what we will have once we get there will be a paradigm shift, a completely different type of programming language.

I propose that the new language that we try does concurrency by default and that in general a programmer will have to write specific instructions in order to bypass the built-in concurrency features and get a non-concurrent process or structure.

Herb Sutter advocates new languages for concurrency

2006-11-25T07:27:00.000-05:00

I agree with Herb on that one and on other issues. Here are two seminal documents from Herb.

http://www.gotw.ca/publications/concurrency-ddj.htm - Updated version of The free lunch is over article.

http://irbseminars.intel-research.net/HerbSutter.pdf - Slides of Herb's presentation at Intel Research, Berkeley, California, September 25, 2006.

TODO here summary of Herb's views.

Herb is a C++ guru currently working on general concurrency issues, including a project at Microsoft. His distinguishing argument is for a gradual evolution of programming languages and techniques (IDEs, APIs) towards easier concurrent program development.

CSP for Java On IBM Developerworks

2006-11-16T18:55:00.000-05:00

This is a 3 part series. Very important.

CSP = Communicating Sequential Processes

The main questions for us about CSP are:

What are the situations where CSP may be advantageous?
If any, then when do we use it instead of using java.util.concurrent directly?

We will try to answer these questions in this blog, as well as other questions.

IBM Thread and Monitor Dump Analyzer for Java

2006-11-16T18:52:00.000-05:00

version 1.0.4

Thread Threat - Vladimir Roubtsov, JavaWorld.com, Feb. 2003

2006-11-16T18:48:00.000-05:00

An introduction to concurrency.

Characteristics of Thread-Safe Programs

2006-11-12T17:25:00.000-05:00

1. It is usually easier to design thread safety at an early design stage than to modify existing code.

2. A program consisting of thread-safe classes may not be thread-safe and a thread-safe program may contain some classes that are not thread-safe. (jcip p.15)

3. We do not yet have a formal definition of thread safety in general and we do not have formal techniques for stating a complete definition of thread safety for a given class. This poor state of affairs in the world of so-called computer science is mainly due to the lack of a technique for formal and complete definitions of program correctness. If any such techniques exist, they are not in common use, at least not in commercial software. Techniques that I studied for this purpose, in the 1980's for example, where often more complex than the code that they were describing.

4. In theory, a correct class means that the class conforms to its specification (what it is supposed to do). And frequently, classes specifications are vague (i.e., informal and incomplete) and single-threaded correctness is often assumed when no incorrect behavior is observed. In many cases, the source code of the class is the specification. In the best cases, the correctness of a class is defined by associated testing classes and test cases (data sets for testing) that define the input and matching output of each of the methods of the class. The validity of correctness-by-testing is dependent on the correctness of the testing classes and data sets. This is like a house of cards.

5. The definition of thread-safe class from the JCiP book: A class is thread-safe when it behaves correctly for a single thread and it continues to behave correctly when used by multiple threads, and with no additional synchronization or other coordination on the part of the calling code.

6. My current definition of a thread-safe class: A class is deemed thread-safe when it complies with the Mandatory Basic Rules in this blog.

Mandatory Rules for Safe Multithreading in Java in 2006

2006-11-12T15:09:00.000-05:00

Much of this post is inspired by the first few chapters of the jcip book. It is also based on my experience.

1) State Variables Must be Synchronized: When more than one thread access a state variable (var), and one of them might write to it, then they all must synchronize their access to it.

1.1. A state var is a variable for a single instance or all instances of a class, aka. instance var and class var respectively. A state var is also called a field. It is not a variable defined in a method; these local vars defined in a method are thread-safe because they cannot be shared with other threads (unless they are copied to some other location that can be shared). In Java, an instance var is defined as non-static (the static qualifier is absent) and a class var uses the static qualifier. It is a common and critical misconception to consider that instance variables are thread-safe and that only static variables need protection (e.g., a guard or lock).

1.2. A stateless class is thread-safe if it uses only thread-safe classes. A stateless class is one that has no fields and that does not reference any fields from other classes. It may have local variables, i.e., variables defined in a method.

2) Missing Synchronization Is a Defect: A program that is missing needed synchronization may appear to work well for years but may fail at any moment and must be considered defective and must be fixed urgently.

2.1. The occurrences of programs with missing synchronization exhibiting erroneous behavior and producing incorrect data will be greatly increased with the advent of multicore chips in desktop computers and in servers replacing single-chip machines.

2.2. Applications that have been exhibiting correct behavior on SMP machines should show less of an increase in the frequency of multithreaded defects than applications running on single chip machines. This is only about the predicted increase in frequency of multithreading defects and rule #2 still applies to applications that have been running on SMP servers, i.e., if they are missing synchronization then they are defective.

3) How to Synchronize: There are 4 basic ways to fix synchronization defects for a given state var:

3.1. Don't share the state var across threads, if possible,

or

3.2. Make the state var final, if possible,

or

3.3. Synchronize accesses to the state var; if the previous two options are not possible then this one is mandatory. The ways to synchronize access to a state var:

3.3.1. In some cases you may use a java.util.concurrent.atomic (j.u.c.a.) class instead of a regular (non atomic) primitive; this is sufficient when the class has only one state var, or the state vars are not interdependent, but is not sufficient when it has more than one state vars that need to coordinate/synchronize their updates; the atomic classes cannot be used for this coordination, therefore, in such cases, instead of atomic vars, you must use an atomic set of operations, e.g., a set of operations bounded by a lock (rule 3.3.2). In some cases, an atomic class from j.u.c.a cannot appropriately replace its corresponding primitive. The j.u.c.a. classes are primarily designed for developing non-blocking algorithms, a particular type of concurrent logic.

3.3.2. Use an atomic set of operations (e.g., a set of operations bounded by a lock) to update interdependent state variables.

3.3.3. If coordinated access is being done on a var, then synchronize with the same lock for all uses of that var and all the invariants in which it and its related vars may participate, including reading the var(s). This situation is called *guarded by a lock* and the @GuardedBy("aLock") annotation is to be used for each state var that need to be coordinated.

3.3.3.1. Use block synchronization of minimal sizes while minimizing the number of such blocks in each method. Possible strategy: use method synchronization (sync) when this does not affect performance significantly; otherwise use block synchronization within the method. In determining the minimal block size, try to not include local vars in block, because local vars (stack-based) are not shared across threads and do not require synchronization. Favor sync blocks that do not include calls to methods of other objects, particularly those that are lengthy or that involve operations that may block (e.g., I/O, network). Favor a small number of sync blocks per methods because each sync block has a cpu overhead cost. Nevertheless, thread safety must never be compromised and cpu cycles must be spent.

or

3.4. Make the Entire Class Immutable: this is my favorite solution when possible. An immutable class is one whose state cannot be seen to change by callers (aka. clients). This requires that:
- all public fields are final,
- all public final reference fields refer to other immutable objects, and
- constructors and methods do not publish references to any hidden state which is potentially changeable (mutable); in particular, the *this* reference must not escape from any of the constructors of the class.

3.4.1. Immutable objects may still have hidden mutable state for purposes of performance optimization; some state vars may be lazily computed, as long as they are computed from immutable state and that clients cannot tell the difference (they are hidden from the clients).

3.4.2. Immutable objects are thread-safe; they may be passed between threads or published without synchronization.

3.4.3. Making a static field immutable: use *final*, do not deserialize the class, and the field must contain a primitive or an instance of a class which is itself thread-safe. This will ensure atomicity and visibility for a static field.

3.4.4. Making a NON-STATIC field immutable (an instance field): use *final* and make sure that all constructors cannot let *this* escape. Immutable classes must have thread-safe constructors. The final fields may be made public, and accessor methods are not needed, which also improves performance.

3.4.5. Serialization: It may be possible to create an immutable class that can be serialized and deserialized, but it may be so complex that it may not be worth the development costs, and in general, if a class needs to be serialized and deserialized, it may be less expensive to not try to make it immutable and to make it a plain thread-safe class.

3.4.6. For similar reasons than for 3.4.5. Serialization, in general, it is usually expedient to not make immutable beans or classes that are loaded programmatically, if that bean or programmatic class has fields that require values set by the constructor(s) parameters, which is often the case.

4) How to use VOLATILE:

4.1. Try not to use volatile - use volatile only when all these conditions are met:

- writing to the shared var without using its current value or when only a single thread updates the var;

- and the var is not involved in an invariant relation;

- and the var is not of type long or double: these primitives are not atomic and such shared vars must be guarded by a lock or, for a long not involved in an invariant, an AtomicLong, instead of a volatile qualifier, and for a double not involved in an invariant, a BigDecimal may be considered (because it is immutable thus thread-safe, although a BigDecimal may be slower than using a lock); volatile cannot guarantee atomicity and also do not protect invariants;

- and you are absolutely certain that locking is not required while the var is being accessed.

4.2. Examples of typical use of volatile: Ensuring visibility (without the need for atomicity), e.g., boolean event notification, such as single change boolean (initialization or shutdown state indicator), or a status flag used to exit a loop. The above conditions in 4.1 must always be met.

4.3. When in doubt, use locking instead of volatile.

5) Java 5 or Above: Do not use pre-Java 5 versions. The above rules only apply to Java 5 or later, and earlier versions of Java must not be used for mutithreaded apps. This is because the memory model was fixed in Java 5 to ensure thread-safety and the earlier versions of Java are inherently not thread-safe (unless a vendor has rendered it's implementation of Java thread-safe before Java 5), and when using earlier versions of Java, developers cannot be guaranteed that using the above mandatory rules will ensure thread-safety.

Non-Mandatory Rules:

a) When a state var is protected by synchronization (i.e., a lock), do not use an atomic type from java.util.concurrent.atomic to store the value; use a regular type because this helps performance and code simplicity (better speed and lower maintenance costs).

b) In your code, use the annotations defined by Brian Goetz and Tim Peierls (used in the JCiP book): ThreadSafe, Immutable, GuardedBy.

c) Always use the -server option for the java command, even in development (of concurrent applications), when this option is available.

d) Do not assume that any class is thread-safe, including classes from the Java SE API, unless you analyze the source code, or the class is documented to be thread-safe and you trust the developer(s). I trust the Java SE developers but unfortunately the documentation of many of their classes do not specify whether the class is safe or not.

e) Question: what's the difference between int and AtomicInteger? Is int atomic? jcip p. 36 states that lower than 64-bit vars are atomic. If int is atomic, then why use AtomicInteger?
Answer: Assigning an int is atomic but operations on an int that depend on its previous value are not atomic, so AtomicInteger is designed for atomic operations with the previous value of the field. Also, an AtomicInteger is used in applications such as atomically incremented counters, and usually cannot be used as a replacement for an Integer. Atomic classes in java.util.concurrent.atomic are designed primarily for implementing non-blocking data structures and related infrastructure classes. The compareAndSet method that they use is not a general replacement for locking because it applies only when critical updates for an object are confined to a single variable and therefore it is not applicable to invariants.

f) Q: How come no AtomicDouble in JSR 166?
A: Because their use is very uncommon. Generally, a double field is guarded by a lock and not by an atomic class. You can easily convert an AtomicInteger and an AtomicLong into either a float or double by using their floatValue() and doubleValue() methods.

g) Values representing amounts of currency should always use BigDecimal (for precision reasons, not for concurrency) and a BigDecimal is immutable thus thread-safe.

TODO rendering thread-safe applications composed of thread-safe classes (in other posts).

TODO locking protocols, sync. policies (in other posts).

TODO safety of classes generated by xjc tool in JAXB (in other posts).

Copyright (c) 2006 Serge Masse.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license is in http://www.gnu.org/licenses/fdl.txt

The Java annotations (e.g., @GuardedBy, @Immutable, @ThreadSafe) in this post are copyrighted by Brian Goetz and Tim Peierls under these terms:
Copyright (c) 2005 Brian Goetz and Tim Peierls
Released under the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.5)
Official home: http://www.jcip.net
Any republication or derived work distributed in source code form must include this copyright and license notice.

JSR-166 and the JCIP book

2006-11-12T12:55:00.000-05:00

One of the best toolkit today for concurrent programming is the JSR-166 API in Java SE 5 and the related mailing list, concurrency-interest, and book, Java Concurrency In Practice (JCIP).

Nevertheless, the use of these tools show that it is still very difficult to build concurrent applications and that we need even better tools, such as a new programming language and/or development tools.

And until then, JSR-166, with the great support from Doug Lea and his team, are the best that we have.

first post on multithreading

2006-11-12T12:04:00.000-05:00

only the critical programming issues, with an emphasis on Java.