Nick Widelec wrote:
Henry Wong wrote:
Yes, it is possible to have more than one Condition variable with the same lock. However, I am not sure of your question -- why should this not be possible?
Henry
Hi Henry,
I am not saying that it is impossible, or why it is possible or anything. I would like just to know how it works, is it supported merely by the management of the intrinsic lock or there is something more which comes with the locks package?
I know I should go through the source code However I am running out of time (in preparing the exam). So if somebody knows in short how it works and has time to share it responding to this question, thanks in advance.
How would this knowledge help with the exam?? Well... okay...
Condition variables are highly integrated with it corresponding Mutex lock. In this case, the Condition class is highly integrated with the ReentrantLock class. Obviously, the reason for this is because condition variables do things with the lock that can't be done with the public interface -- such as release all the nested locks atomically.
As an implementation detail, The ReentrantLock class (along with it's Condition Class) do not use the
Java synchronization mechanism. Instead it use the atomic classes, which in turn, uses JNI to get to features based around the processor's CAS operator. As an FYI, the CAS operator is what synchronization is implemented with, so the Lock/Condition classes goes even lower than synchronization to be implemented.
Interestingly, the last time that I checked, the Lock/Condition classes doesn't use the underlying mutex/condition variables of the operating system either -- instead choosing to go to the CAS operator directly. In my opinion, this was likely a bad idea, as most OSes support priority inheritance with mutex locks, which currently, I don't think is supported by the ReentrantLock class (perhaps it can be implemented in the future).
Henry