title: Some questions on java multithreading,
body: <p>I have a set of questions regarding Java multithreading issues. Please provide me with as much help as you can.</p>
  
  <p><strong>0)</strong> Assume we have 2 banking accounts and we need to transfer money between them in a thread-safe way. 
  i.e. </p>
  
  <pre><code>accountA.money += transferSum; 
  accountB.money -= transferSum; 
  </code></pre>
  
  <p>Two requirements exist:</p>
  
  <ol>
  <li>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) </li>
  <li>reading access should not be blocked during the operation (i.e. old values of account sums should be shown during the operation goes on) </li>
  </ol>
  
  <p>Can you suggest some ideas on this? </p>
  
  <p><strong>1)</strong> 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. - <strong>is it correct?</strong> </p>
  
  <p><strong>2)</strong> How long a thread that is awoken by notify method can wait for a lock? Assume we have a code like this: </p>
  
  <pre><code>synchronized(lock) {  
      lock.notifyall();   
      //do some very-very long activity  
      lock.wait() //or the end of synchronized block  
  }  
  </code></pre>
  
  <p>Can we state that at least one thread will succeed and grab the lock? Can a signal be lost due to some timeout? </p>
  
  <p><strong>3)</strong> A quotation from Java Concurrency Book:</p>
  
  <p>"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."</p>
  
  <p>Does this mean that the only thread-safety issue that remains for a code being 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. </p>
  
  <p><strong>4)</strong> All standard getters and setters are atomic. They need not to be synchronized if the field is marked as volatile. - <strong>is it correct?</strong> </p>
  
  <p><strong>5)</strong> The initiation of static fields and static blocks is accomplished by one thread and thus need not to be synchronized. - <strong>is it correct?</strong> </p>
  
  <p><strong>6)</strong> Why a thread needs to notify others if it leaves the lock with wait() method, but does not need to do this if it leaves the lock by exiting the synchronized block?</p>