Forums Register Login

One question on java method call

+Pie Number of slices to send: Send
I have a question on java method syncronization.
In class test ,i have one syncronized method a() and another non syncronized method b().
Now if one thread accessing method a ,so it locked the object,
Case is that, first thread has not yet finished executing syncronized method a ,then another thread calls non syncronized method b().
will second thread will be able to excute method b ,simutaneously with first thread executing method a.
+Pie Number of slices to send: Send
Yes, absolutely. Unsynchronized methods, by definition, are unaffected by synchronization.
+Pie Number of slices to send: Send
But as method a is syncronized,so object is locked .until that lock is released ,how another thread will access that object,for method call b
+Pie Number of slices to send: Send
Only synchronized methods care about that "lock." Unsynchronized methods don't even check it. The lock isn't a magical thing that has the power to stop method calls; it's only because a synchronized method contains code to check the lock before starting that synchronization works. There's a special bytecode "monitorenter" that handles this checking.

Anywau, don't think of a lock like a lock on the door; think of it as a signal. Imagine that two roommates have an arrangement: if roommate A comes home and finds a necktie hanging on the doorknob, he knows roommate B is inside entertaining a lady friend, and so he should not come in. This works fine for A and B, because they both know about the arrangement. A and B are like synchronized methods, the apartment is like the locked object, and the necktie is the lock (most Java people call it a "monitor.")

Now, imagine they have a friend C. C knows nothing about this arrangement. C comes along, sees the necktie on the doorknob, says "Huh, I wonder why there's a necktie on the doorknob", opens the door, and says, "Hey, how come there's a necktie hanging on... ooops, sorry..." and leaves, embarrassed.

C is like an unsynchronized method. He totally ignores the necktie.

I'm going to move this thread to our "Threads and Synchronization" forum for followup.
+Pie Number of slices to send: Send
Thanks Ernest for your detailed explanation.
what i understand now is object lock or monitor is only for syncronized method call.
But here is my question,
in this scenario i get the object using singleton pattern
and if getInstance() method is syncronized, then what will happened to second thread for calling method B.
+Pie Number of slices to send: Send
getInstance() is static, right? You don't say what kind of method B is here.

Every loaded class has an instance of java.lang.Class that represents it in the JVM. Static synchronized methods use the monitor belonging to the java.lang.Class object for their class; therefor static synchronized methods are separate from instance synchronized methods; the two don't interfere.
+Pie Number of slices to send: Send


yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer
.Thanks in advance
+Pie Number of slices to send: Send
 

Originally posted by indrakolkata saha:


yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer
.Thanks in advance



I can't tell what you're asking this time.
+Pie Number of slices to send: Send
 

Originally posted by indrakolkata saha:

yes method b is non syncronized here.so what will happen in this case means using static singleton getInstance method as a object initilizer
.Thanks in advance



Well, it depends on what your getInstance() method really does!

For example, inside your getInstance() method you have a sleep(5000) call - basically you are forcing the thread to sleep for 5000 seconds. And within this 5000 seconds, you have a second thread that is attempting to call method b. Then -

In order for thread 2 to call method b, it should first get the object using a call to getInstance(), right?

Given this situation, thread 2 will have to wait till it gets the lock (after thread 1 has completed its sleep and released the lock by exiting the synchronized block of code). So, yes in this case thread 2 can not call the unsynchronized method b.

Is this scenario anything close to what you have in mind ?

- m
+Pie Number of slices to send: Send
I also agree with you.May be Mr Ernest Friedman-Hill can highlight on this topic.
Thanks
mooooooo ..... tiny ad ....
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1143 times.
Similar Threads
doubt in calling thread..
A bunch of thread questions!
Sychronization
Am I right about wait() and notifyAll()
Wait state vs. blocked state ?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 03:41:48.