Thread question

[Ellai John Dinglasan]

Hi I have this piece of code
synchronized(thing){
thing.flag=false;
if(thing.flag==false){
System.out.println(thing.flag);
Thread.sleep(1000);
System.out.println(thing.flag);
}
}
I checked out the java documentation and it says that calling sleep does not make a Thread loose a monitor.
After this thread sleeps I have another thread who accessed the object "thing" and was able to change thing.flag variable.
So when my first thread runs again it thing.flag has a new value.
Any thoughts on this is appreciated.
Thanks!

[Eddie Vanda]

Hi Ellai,
Is thing the name of a class, method or object? I'm a bit conservative and I usually access a critical object via a single synchronized method.
Ed

[Tony Morris]

First off, a conditional expression that tests equality with two boolean operands is poor form.
if(thing.flag==false) should read if(!thing.flag)
Much nicer

No, Thread.sleep does not cause the thread to lose any monitor.
Now, what you are getting at in this case is a little bit unclear, so I will speculate. One important point to note is that 'thing' (probably if my speculation is right) should be declared volatile.
You run this piece of code, have another thread modify the value of thing (do you know when ?), and then when you run it again the value has been changed ?
This is the correct behaviour, although I don't know if this is what you mean. A test case as such usually requires three things:
- Some source code (or equivalent depending on circumstances) so that others can reproduce the situation (granted, this is not always easy when dealing with threads).
- Your expected outcome. What did *you* think was going happen ?
- Your actual outcome.
It is very important to express your expected and actual outcomes clearly; what you have described appears to be very ambiguous.

[Ellai John Dinglasan]

Hi!
"thing" is just an instance of an object with an ordinary boolean member named "flag".
I have two threads which both have reference to "thing". Lets call them T1 nad T2.
Inside the run method of T1, I synchronized the object "thing". And set T1 to sleep while inside the synchronized block. T2 was able to change the value of thing.flag while T1 was sleeping.
I was expecting T2 not to be able to update thing.flag because sleeping T1 still has a lock on it.
Thanks!

[Warren Dew]

Synchronizing on an object does not prevent all access to the object; it only prevents synchronized access to the object. If "flag" is a public data member of the object, another thread may change the value of thing.flag without first synchronizing on "thing". That's probably what you are seeing.
You'll need to change the other thread's access to the object to synchronize on it as well, or (better) make "flag" a private data field with synchronized accessors (get and set functions).
Warren

[Ellai John Dinglasan]

Synchornizing doesn't stop other threads to change the attributes of an object while it is locked. That was my understanding of the previous reply.
Is my interpretation correct?
If so, so what is the purpose of synchornizing if you cannot lock the object?
Thanks!

[Ernest Friedman-Hill]

Originally posted by Ellai John Dinglasan:
Synchornizing doesn't stop other threads to change the attributes of an object while it is locked. That was my understanding of the previous reply.
Is my interpretation correct?

Yes.

If so, so what is the purpose of synchornizing if you cannot lock the object?

Good programing practice demands that member variables be private in most circumstances; all access to them should be through methods. Then all you need to do is make sure that (at least) all methods that modify the member variables be synchronized. If you do this, then locking the object does indeed prevent modification to member variables.

[Taikonaut five]

Hi,
When you access thing.flat in T2, you should use this
synchronized(thing). synchornized mean that no more than
threads can't access that code section, or access code that
synchronized in other

[Mr. C Lamont Gilbert]

The lock object you use in your synchronization statement and the section of code you are protecting have no relationship with each other.