thread safe

[kri shan]

What is thread safe ? What is the use of thread-safe ?

[Jonathan Hall]

Making an application "thread-safe" mostly applies to applications that use database tables. Thread-safe applications allow multiple users to use your application at the same time without one user updating a record,or deleting a record, if another user is in the middle of using that same record. Because the processor on a computer doesn't not really simultaneously work with two users (threads) at the same time, the processor switches back and forth between threads very quickly. This means that one user can be looking at or working on a record in a database just before the processor switches processing over to another user who updates that same record that the first user was just looking at or working on. As a result, any data that the first user was relying on from that record may not be correct since the second user updated that record without the first user's knowledge.
[ July 27, 2004: Message edited by: Jonathan Hall ]

[Peter den Haan]

Originally posted by Jonathan Hall:
Making an application "thread-safe" mostly applies to applications that use database tables.

Not precisely. That is something that the database itself, and (long) transactions, take care of.

Thread safety has nothing to do with databases specifically, and everything with the behaviour of regular Java code when accessed by multiple threads. Consider a piece of code like this:

private int number;
 
public int nextNumber() {
   number = number + 1;
   return number;
}

If this code is called by two threads at the same time, the following scenario may happen. Call the threads A and B, and assume that number starts out with the value 10. The code may be executed in the following order:

A: number = number + 1;      // number will now be 11
B: number = number + 1;      // number will now be 12
A: return number;            // thread A will get 12
B: return number;            // thread B will get 12

You will have skipped a number (11) and given the same value (12) to both threads - this is almost certainly not what you expected!

The problem is caused by the fact that the act of incrementing the number and returning the value is not atomic with respect to other threads. In other words, these two steps need to be an indivisible unit that can only be executed by one thread at a time. This is where synchronization comes in:

private int number;
 
public synchronized int nextNumber() {
   number = number + 1;
   return number;
}

Thread B will now be prevented from executing nextNumber() as long as thread A is executing it. The scenario above can no longer happen:

                             // A enters the method and acquires a lock
A: number = number + 1;      // number will now be 11
                             // B is prevented from entering the method
A: return number;            // thread A will get 11
                             // A releases its lock and B enters the method
B: number = number + 1;      // number will now be 12
B: return number;            // thread B will get 12
                             // B releases its lock

This is the result you would hope for.

Although this explains the basics of thread safety, it hardly scratches the surface of this complex subject. For more information, read the Java Thread tutorial and Doug Lea's classic Concurrent Programming in Java.

And, as a final word, sooner or later someone will try to tell you that "this code is threadsafe because it uses a Vector, and Vectors are threadsafe". This is totally wrong. Vector is synchronized. That does not make your code threadsafe, because Vector's synchronization is probably in the wrong place. The operations that need to be atomic are usually not the little Vector operations, but larger composite operations that you write. This is why Sun made the new collections framework classes such as ArrayList totally unsynchronized, and one of the reasons why you should never use Vector, Hashtable and friends if you can avoid them.

Hope this helps

- Peter
[ July 27, 2004: Message edited by: Peter den Haan ]

[Dirk Schreckmann]

Moving this to the Threads and Synchronization forum...