Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Accessing two synchronized methods, when the object is locked !!!

 
S.R Paul
Ranch Hand
Posts: 30
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers!
I have some questions regarding Synchronization.

It's true if the running instance of a synched method is locked by a thread, then
1. the specific synched code cannot be accessed by any other thread
2. any non-synched methods or code can be accessed by other threads

Question is, what is the type of restriction on another synched method / code block written in the very same class?
Can it be accessed by another thread? (at the same time, while the object is locked)

I think, since there is only one lock per object, it is not possible. BUT need confirmation.

Expects a solid answer
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
S.R Paul wrote:Hi Ranchers!
I have some questions regarding Synchronization.

It's true if the running instance of a synched method is locked by a thread, then
1. the specific synched code cannot be accessed by any other thread
2. any non-synched methods or code can be accessed by other threads


You're terminology is a little off, but if you mean what I think you mean, then, yes, that's correct.

Question is, what is the type of restriction on another synched method / code block written in the very same class?
Can it be accessed by another thread? (at the same time, while the object is locked)


No, as long as both methods are static or both are non-static.

I think, since there is only one lock per object, it is not possible. BUT need confirmation.


That is correct.

A few key things worth knowing. Synchronization is really quite simple in terms of what it does for mutual exclusion. Hitting a synced block or method does one thing and one thing only in terms of mutual exclusion: It obtains an object's lock, waiting first until it's released if a different thread currently holds it. A lock is released when we exit a sync block, call wait(), or when the thread dies. In order to answer any question about which thread can run which code, all you need to know is that, and the following:



That is, declaring a method synchronized is no more than syntactic sugar for explicitly syncing on a particular object, with that object being determined by the context.

Expects a solid answer


That sounds kind of bossy. Comments like that run the risk of alienating the people whose help you seek.
 
S.R Paul
Ranch Hand
Posts: 30
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all, Thank you Jeff.

No, as long as both methods are static or both are non-static.

The answer No satisfies me, but what is the impact when we mixed up static and non-static while both are Synchronized (code block or method).
Means, one static synched code and one non-static synched code.

That sounds kind of bossy. Comments like that run the risk of alienating the people whose help you seek.

Ok, Sorry. I didn't mean to be bossy, but I implied solid as straight forward without wandering.
I'm still greenHorn
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
S.R Paul wrote:First of all, Thank you Jeff.

You're quite welcome.

No, as long as both methods are static or both are non-static.

The answer No satisfies me, but what is the impact when we mixed up static and non-static while both are Synchronized (code block or method).
Means, one static synched code and one non-static synched code.

As you can see from my previous post, a synced non-static method obtains the lock for "this", while a synced static method obtains the lock for the Class object. Two different objects, two different locks, so no mutual exclusion.

That sounds kind of bossy. Comments like that run the risk of alienating the people whose help you seek.

Ok, Sorry. I didn't mean to be bossy, but I implied solid as straight forward without wandering.
I'm still greenHorn

I'm sure you didn't mean it to be rude or bossy. I just wanted to let you know how it might sound so that you don't inadvertently offend somebody.
 
S.R Paul
Ranch Hand
Posts: 30
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two different objects, two different locks, so no mutual exclusion.

That's clear.

Again, Thank you for your concern and answer.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic