A set of questions on concurrency.

[Dmitry Zhuravlev]

Greetings Gentlemen! (and Ladies, if any found)

Here is a set of questions which resulted from my on-going effort to study java concurrency. Please help if possible.

0) Imagine we have 2 banking accounts and we need to transfer money between them in a thread-safe way.
i.e.
accountA.money += transferSum;
accountB.money -= transferSum;

2 requirements exist:
1. no one should be able to see the intermediate results of the operation (i.e. one acount sum is increased, but others is not yet decreased)
2. reading access should not be blocked during the operation (i.e. old values of account sums should be shown during the operation goes on)

Can you suggest some ideas on this?

1) Assume 2 threads modify some class field via synchronized method or utilizing an explicit lock. Regardless of synchronization, there are no guarantee that this field will be visible to threads, that read it via NOT synchronized method. - is it correct?

2) How long a thread that is awaked by notify method can wait for a lock? Assume we have a code like this:

synchronized(lock) {
lock.notifyall(); 
//do some very-very long activity
lock.wait() //or the end of synchronized block
}

Can we state that at least one thread will succeed and grab the lock? Can a signal be lost due to some timeout?

3) a quotation from Java Concurrency Book:
Single-threaded executors also provide sufficient internal synchronization to guarantee that any memory writes made by tasks are visible to
subsequent tasks; this means that objects can be safely confined to the "task thread" even though that thread may be replaced with another from
time to time.
Does this mean that the only thread-safety issue that remains if a code is executed in Single-threaded executor is data race and we can abandon the volatile variables and overlook all visibility issues? It looks like a universal way to solve a great part of concurrency issues.

4) All standart getters and setters are atomic. They need not to be synchronized if the field is marked as volatile. - is it correct?

5) The initiation of static fields and static blocks is accomplished by one thread and thus need not to be synchronized. - is it correct?

6) Why a thread needs to notify others if it leaves the lock with wait() method, but do not needs to do this if it leaves the lock by exiting the synchronized block?

[Chris Hurst]

0) I suggest some background reading on transactions in J2EE / Spring which should give you a good grounding in the issues even if you are not using these frameworks.

1) A not seems to be missing and obviously volatile for instance gives you visibility.

2) Signals can be lost if nothing is listening and unsolicited signals can be heard (wait wakes up with no notify)... see spurious thread wake up.

wait documentation

3) It means the internal implementation gives you visibility e.g. if the task issuer has to sync to get a job onto the single thread task executor you have happens before ordering BUT be careful it only refers to these threads if you have a unrelated thread that can see get the result of the tasks e.g. its exposed by a global variable you could still have problems.

4) Well volatile solves all your visibility issues but you still have a standard race condition e.g. if your getter is just updating an object your setter just modifies fields on you can still see half the sets unless your getter always returns a new reference.

5) Statics are fine this is discussed in the Java memory model documentation.

6) Different thread states ...

blocked vs waiting