Hi all,
my class uses some thread safe objects, but sometimes I want to atomically update some of these objects. Is the following code legal?
publicclass MyClass{
private ThreadSafeClass1 one;
private ThreadSafeClass2 two;
private Lock lock;
//initialization here...
publicvoid method1(){
one.one();
}
publicvoid method2(){
two.two();
}
publicvoid method3(){
lock.lock();
try{
one.three();
two.four();
}finally{
lock.unlock();
}
}
I forgot...., this could happen as well
public void method4() {
one.three();
}
public void method5() {
two.four();
}
You cannot atomically update an Object, only primatives.
Sometimes you Lock and sometimes you don't. But we seen no code as to what is actually happening.
Your question "is this legal" doesn't compute.
You can specify a volatile field and use Lock to restrict access to it. You can also use one of the fieldUpdater's in the atomic class to update the field atomically.
We need a little more information on what you are doing and what you are looking for.
When I write 'atomically' I mean without external interferences.
As I said, the two object are thread safe. They are internally protected by locks,
so all calls are thread safe.
What I want in method3 is to 'atomically' (see above) update the two objects.
Without lock, in fact, given 2 threads calling method3(), could happen:
T1 --> one.three
T2 --> one.three
T2 --> two.four
T1 --> two.four
More in detail, in method3() I use object1 to store something into a queue and object2 to increment a counter (the queue size and this counter are related, but they don't hold the same value)
The counter is not in object1 because it's heavily used in object2
Ok, I'll try to restate the problem.
I've a class which contains two thread safe objects. What should I do if I want to atomically update both objects (i.e. with no interference from another thread)? Is it correct to do something like this?
public class MyClass {
private ThreadSafeClass1 one;
private ThreadSafeClass2 two;
private Lock lock;
//initialization here...
public void method1() {
one.one();
}
public void method2() {
two.two();
}
public void method3() {
lock.lock();
try {
one.three();
two.four();
} finally {
lock.unlock();
}
public void method4() {
one.three();
}
public void method5() {
two.four();
}
}
> You keep using the term "thread safe". Well, if the
> object is thread safe then you don't have to do
> anything.
I said ThreadSafeClass1 and 'ThreadSafeClass2 are thread safe. I didn't say anithing about MyClass. And in fact this is my question.
>
> You keep using "atomic". That word has special
> meaning in CS.
>
Why do you want to do the teacher? What you actually get is just to look nasty. Why don't you try to explain to Doug Lea what 'atomic' means? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ArrayBlockingQueue.html#clear()
I guess in the link above, 'Atomically' has the same definition I gave you in my previous post.
> Good luck.
If you don't know the response you could simply say "i'm sorry, I don't know" instead of beeing so boring about useless details
Some folks that hang around here can be a little pedantic about words and meanings. "legal" has no meaning with respect to either thread-safety or atomicity.
The code you showed is generally not correct if you want the updates to objects one and two to be atomic in method3() because there is nothing to stop method1() and method2() being called concurrently. So they actual sequence of method calls on objects one are two is indeterminate. Now whether an interleaving such as:
one.three();
one.one();
two.two();
two.four();
is harmful or not depends on what those methods do. But assuming they each change the object's state in some way, then you certainly do not have atomicity.
In general you can not provide an atomic sequence of operations over one or more objects unless you control all access to those objects and so can enforce the necessary locking protocol - eg. method1(), method2() etc use the same lock as method3().
Often when you analyze why the actions on the different objects must be atomic you recognize that these objects form an additional abstraction that should itself be represented as its own object with its own API and which can define its own atomic operations. Now whether you can then compose such an object from the pre-existing ones all depends, but typically you can't - it is far easier to synchronize composed objects, than to compose synchronized ones.
> Ok, I'll try to restate the problem.
> I've a class which contains two thread safe objects.
> What should I do if I want to atomically update both
> objects (i.e. with no interference from another
> thread)? Is it correct to do something like this?
>
> > public class MyClass {
>
>private ThreadSafeClass1 one;
> private ThreadSafeClass2 two;
>private Lock lock;
>
>
>//initialization here...
>
>public void method1() {
>one.one();
>
>
>public void method2() {
>two.two();
>
>
> public void method3() {
>lock.lock();
> try {
> one.three();
> two.four();
>} finally {
>lock.unlock();
> }
>
>public void method4() {
> one.three();
> }
>
> ublic void method5() {
> two.four();
>
>
> }
>
>
I dont quite know the semantics of "lock.lock", but I am going to go out on a limb and say no, what you are doing is not proper. You need to invoke the same lock during method 1 and method 2, else those methods will happily ignore the lock and modify the object regardless of what method3 is doing.