I would like to know the logic/reason behind an object getting locked by a thread after it calls a synchronized method of that object. When an object gets locked by a thread, no other thread can call any synchronized method on that object, but still they can call any non-synchronized methods on that object. I would like to know the rationale behind this.
> I would like to know the logic/reason behind an
> object getting locked by a thread after it calls a
> synchronized method of that object. When an object
> gets locked by a thread, no other thread can call any
> synchronized method on that object, but still they
> can call any non-synchronized methods on that object.
> I would like to know the rationale behind this.
In simple terms, the non-synchronized methods are not changing the STATE or modifying the contents of the locked object, so it is ok for those methods to run and use the object.
Hope that helps....
c2gill, I had earlier thought on the similar lines of what u have said in ur reply. But it is not a language restriction that non-sync methods can not change the state of a locked object. I think it is up to the author/designer of the code who needs to take care of it that the non-sync methods should(or must) not change the state of a locked object. Since a sync and a non-sync method can run parrellally from different threads, it is very likely that while a sync method is in the middle of modifying the state of a locked object, some un-sync method from a different thread changes the state, leaving the change done by the sync method meaningless . That means non-sync methods of a class (having sync methods as well) should only be accessors, not mutators (or at least should not be able to modify the variables that are modified inside sync methods). Am I thinking in the right direction?
> c2gill, I had earlier thought on the similar lines of
> what u have said in ur reply. But it is not a
> language restriction that non-sync methods can not
> change the state of a locked object. I think it is up
> to the author/designer of the code who needs to take
> care of it that the non-sync methods should(or must)
> not change the state of a locked object.
That is correct.
> Since a sync
> and a non-sync method can run parrellally from
> different threads, it is very likely that while a
> sync method is in the middle of modifying the state
> of a locked object, some un-sync method from a
> different thread changes the state,
I wouldn't say "very likely," but anytime access to shared data is only partially synced, it's certainly possible that unsynced access will render the half-assed syncing completely pointless.
> change done by the sync method meaningless . That
> means non-sync methods of a class (having sync
> methods as well) should only be accessors,
Even that's not necessarily enough. Longs and Doubles are not read atomically, so an unsynced read concurrent with a synced write can give invalid results.
Also, if any synced operation is writing more than one field, and the state of the object depends on the new values of both fields in order to be valid, then you have to sync your reads as well.
Also, if you don't sync your reads, then in any given thread, after the first read, it can continue to read its local copy and never see the new value that's been written to main mem.
Jverd is right on the money!
I was going to reply to this earlier because both of my statements were staggeringly wrong. That's what happens before I get my first cup of coffee and I have 10 people waiting on me when I arrive in my office....LOL
We had a good laugh on my end. I showed my responses to fellow workers and got some coffee through the nostril effects on some of them!!!
Let's just say for the rest of the week here at work, I'm going to be known as the leading GOOBER or EXPERT on threads....LOL I will NOT hear the end of it for quite some time...I'm sure of THAT!
I was thinking ten things at once and wrote something entirely different. If I could answer again it would go like this:
The OP asked what was the rationale behind it.
I would say: Sun's Thread model makes you are a controller of your own destiny. That control is in your design! I personnally wouldn't have it any other way, thats why I am a fan of Java!
Ya well, it does happen....If you think that's nuts, you would really get a kick out of watching me walk out of the building at the end of my working day(or night!).
On some busy days, I come walking out of the doors, mind racing 90 to nothing going over my latest project, walk all the way to the end of the parking lot(over 500 yards long), stop, turn around an wonder where the hell I'm at, then realize where I'm at, and then wonder where I parked my truck! THANK GOD the side walk ends or there is no telling where i would end up!!!
OR sitting in an SERIOUS early morning meeting and break out in a giggling fit because I read the word, "rearward expulsion". Of course laughter like that is contagious, so everyone starts laughing and asking what is so funny. I totally lose it now because now I'm wondering how I'm going to explain myself to a room full of professionals!!!
TRUST me, it WON"T be the last nutty thing you hear from me...
All I have a general question on thread synchronization I want to make sure I understand.
if I declare multiple methods in an object as synchronized, is it true that no synchronized method can be called by another thread, or just the one currently locked?
also, consider this case
object with 3 methods all synchronized
1. -> getLengthofStructure
2. -> add to structure
3.-> removefromStructure
now all are synchronized but I believe that a thread "A" could call getlengthofStructure then before it can call one of the other methods, another thread access those methods and modifies the structure such that thread A now has incorrect length information? how is this overcome? is there a way of synchronizing multiple methods? I believe i read somewhere there is a way of just synchronizing access to the entire object?
thanks for the info
> if I declare multiple methods in an object as
> synchronized, is it true that no synchronized method
> can be called by another thread, or just the one
> currently locked?
Neither is true. No other thread can enter any block which is synchronized on that object, including non-static methods. Other threads can call those methods or blocks on other instances of the same class.
> object with 3 methods all synchronized
>
> 1. -> getLengthofStructure
> 2. -> add to structure
> 3.-> removefromStructure
>
> now all are synchronized but I believe that a thread
> "A" could call getlengthofStructure then before it
> can call one of the other methods, another thread
> access those methods and modifies the structure such
> that thread A now has incorrect length information?
> how is this overcome? is there a way of synchronizing
> multiple methods?
> I believe i read somewhere there is
> a way of just synchronizing access to the entire
> object?
Not in the class code. You can do it in the calling code like this:
synchronized (object)
{
int length = object.getLengthofStructure();
object.addToStructure(x,y,z)
object.removeFromStructure(a,b,c);
}
What you are dealing with here is the problem of performing atomic sequences of operations. If the class doesn't define an atomic operation for what you want then your only hope is if the class documents and exposes its locking policy so that you can apply client-side locking in the caller - as ejp just described.
If you look at an interface like ConcurrentMap you will see that it defines composite atomic operations - eg putIfAbsent - just because there is no way to achieve this externally to the map itself (in general).
There is a lot more to writing thread-safe, and thread-useful code, than just using synchronization. See the FAQ and read a good book on the subject.
