多线程和共享对象

Question

If I have a class like :

class MultiThreadEg {

private Member member;

public Integer aMethod() {
    ..............
    ..............
}

public String aThread() {
    ...............
    member.memberMethod(.....);
    Payment py = member.payment();
    py.processPayment();
    ...........................
}

}

Suppose that aThread() is a new thread, then, will accessing the shared member object by too many threads at the same time cause any issues (with the following access rules)?

Rule 1 : ONLY reading, no writing to the object(member).
Rule 2 : For all the objects that need some manipulation(writing/modification), a copy of the original object will be created.

for eg: In the payment() method, I do this :

public class Member {

private Payment memPay;

public payment() {
   Payment py = new Payment(this.memPay);//Class's Object copy constructor will be called.
   return py;
}

}

My concern is that, even though I create object copies for "writing" (like in the method payment() ), acessing the member object by too many threads at the same time will cause some discrepancies.

What is the fact ? Is this implementation reliable in every case (0 or more concurrent accesses) ? Please advise. Thanks.

Answer 1

You could simply use a ReentrantReadWriteLock . That way, you could have multiple threads reading at the same time, without issue, but only one would be allowed to modify data. And Java handles the concurrency for you.

 ReadWriteLock rwl = new ReentrantReadWriteLock();
 Lock readLock = rwl.readLock;
 Lock writeLock = rwl.writeLock;

 public void read() {

    rwl.readLock.lock();
    try {
       // Read as much as you want.
    } finally {
       rwl.readlock.unlock();
    }
 }

 public void writeSomething() {
    rwl.writeLock.lock();
    try {
       // Modify anything you want
    } finally {
       rwl.writeLock.unlock();
    }
 }

Notice that you should lock() before the try block begins, to guarantee the lock has been obtained before even starting. And, putting the unlock() in the finally clause guarantees that, no matter what happens within the try (early return, an exception is thrown, etc), the lock will be released.

Answer 2

In case update to memPay depends on the memPay contents (like memPay.amount+=100) you should block access for other threads when you are updating. This looks like:

mutual exclusion block start
get copy
update copy
publish copy
mutual exclusion block end

Otherwise there could be lost updates when two threads simultaneously begin update memPay object.