• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread question  RSS feed

 
Ellai John Dinglasan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The lock object you use in your synchronization statement and the section of code you are protecting have no relationship with each other.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!