Results 1 to 2 of 2
  1. #1
    KutaBeach is offline Member
    Join Date
    Jul 2011
    Posts
    1
    Rep Power
    0

    Default A set of questions on concurrency.

    Greetings to the Community!

    Gentlemen, 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.

    Java Code:
        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:

    Java Code:
        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 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.

    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?

  2. #2
    doWhile is online now Moderator
    Join Date
    Jul 2010
    Location
    California
    Posts
    1,642
    Rep Power
    7

    Default

    It helps if - rather than dump your homework into the forums - you ask questions questions in a logical way that show you actually want to learn
    Suggested reading: How To Ask Questions The Smart Way

Similar Threads

  1. Practicing Concurrency
    By sunde887 in forum New To Java
    Replies: 1
    Last Post: 06-21-2011, 03:27 AM
  2. Thread concurrency .. What am I missing?
    By Ebodee in forum Advanced Java
    Replies: 5
    Last Post: 02-01-2010, 07:03 AM
  3. GUI Concurrency Problems
    By jkhamler in forum Threads and Synchronization
    Replies: 18
    Last Post: 01-20-2010, 03:40 PM
  4. Concurrency system, and threads.
    By scarymovie in forum New To Java
    Replies: 2
    Last Post: 03-05-2009, 02:20 AM
  5. concurrency question
    By diggitydoggz in forum New To Java
    Replies: 4
    Last Post: 01-17-2009, 03:48 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •