• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

Thread question

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic