Lines Matching refs:Mutex
37 // Native Monitor-Mutex locking - theory of operations
45 // * A thread acquires ownership of a Monitor/Mutex by CASing the LockByte
222 // * Mutex-Monitor is a low-level "leaf" subsystem. That is, the monitor
247 // 4. native Mutex:: and Monitor::
869 // or ILock() thus acquiring the "physical" lock underlying Monitor/Mutex.
877 // If we were to modify the Monitor-Mutex so that TBIVM state transitions tightly
888 // of Mutex-Monitor and instead directly address the underlying design flaw.
933 assert(rank() > Mutex::special, "Potential deadlock with special or lesser rank mutex");
1010 // Mutex-Monitor constructs. We happen to implement JVM_RawMonitors in terms of
1011 // native Mutex-Monitors simply as a matter of convenience. A simple abstraction layer
1199 Mutex::Mutex(int Rank, const char * name, bool allow_vm_block,
1229 st->print_cr("Mutex: [" PTR_FORMAT "/" PTR_FORMAT "] %s - owner: " PTR_FORMAT,
1248 assert(tmp->rank() == Mutex::native ||
1268 assert(tmp->rank() == Mutex::native ||
1296 // It uses the Mutex::_owner, Mutex::_next, and
1314 // Mutex::set_owner_implementation is a friend of Thread
1323 // The rank Mutex::native is an exception in that it is not subject
1328 if (this->rank() != Mutex::native &&
1329 this->rank() != Mutex::suspend_resume &&
1383 || rank() == Mutex::special, "wrong thread state for using locks");
1388 debug_only(if (rank() != Mutex::special) \