Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am not talking about time to take to enter synchronize block.
I am talking about time to take to execute MonitorEnter and MonitorExit statement.
And, how can I measure time to take to execute statement in C(JNI)?
I am developing Android app using Eclipse and OSX.
When dealing with an uncontested lock, the current version of Dalvik uses a fast path that avoids heavyweight thread synchronization operations. In terms of speed, it’s probably about the same as calling a short CPU-bound method written in the Java programming language.
If the lock is contested (that is, two or more threads are interacting with it), then this ends up being a much heavier-weight operation, bottoming out of the VM as calls to the underlying OS’s thread library. That said, it’s typical to expect the time spent doing heavyweight thread operations to be dominated by the actual activity being locked (because if the activity weren’t relatively long-running, you wouldn’t have been so likely to have a contested lock in the first place).
As always, profiling can help you figure this all out.
If you want to peek under the covers, you can find the salient code in
platform/dalvik/vm/Sync.cpp>in the Android sources. Look fordvmLockObject, though you’ll have to wander into the JIT compiler code to get a more complete story.