Lines Matching defs:thread
57 // * A thread acquires ownership of a Monitor/Mutex by CASing the LockByte
59 // is advisory and is used only to verify that the thread calling unlock()
60 // is indeed the last thread to have acquired the lock.
96 // -- Invariant: a thread appears on at most one list -- cxq, EntryList
98 // -- For a given monitor there can be at most one "OnDeck" thread at any
108 // As necessary, the unlock()ing thread identifies, unlinks, and unparks
109 // an "heir presumptive" tentative successor thread from the EntryList.
110 // This becomes the so-called "OnDeck" thread, of which there can be only
115 // The exiting thread does _not_ grant or pass ownership to the
116 // successor thread. (This is also referred to as "handoff" succession").
117 // Instead the exiting thread releases ownership and possibly wakes
122 // be to add an AcquireCounter field to the monitor. After a thread acquires
124 // reaches 0 the thread would reset the AcquireCounter variable, abdicate
125 // the lock directly to some thread on the EntryList, and then move itself to the
134 // detaching thread. This mechanism is immune from the ABA corruption.
137 // thread constraint.
154 // Queue discipline is enforced at ::unlock() time, when the unlocking thread
162 // -- For a given monitor there can be at most one OnDeck thread at any given
163 // instant. The OnDeck thread is contending for the lock, but has been
165 // Once a thread has been designated the OnDeck thread it will remain so
170 // OnDeck by CASing the field from null to non-null. If successful, that thread
172 // drain the cxq into the EntryList. By convention, only this thread, the holder of
176 // to at most one thread. Having selected and detached a successor, the thread then
179 // that the OnDeck usage as a lock is asymmetric. A thread in unlock() transiently
204 // * Note that thread-local storage must be initialized before a thread
223 // the purpose-specific ParkEvents and instead implement a general per-thread
226 // and ::Release(). A thread would simply pop an element from the local stack before it
227 // enqueued or park()ed. When the contention was over the thread would
244 // It's unfortunate that native mutexes and thread state transitions were convolved.
452 // IWait and ILock may directly call park() without any concern for thread state.
485 // At any given time there is at most one ondeck thread.
487 // Only the OnDeck thread can try to acquire -- contended for -- the lock.
518 // and unlink the next ONDECK thread from the EntryList.
519 // If successful, set ONDECK to refer to that thread, otherwise clear ONDECK.
549 // Either we have a valid ondeck thread or ondeck is transiently "locked"
550 // by some exiting thread as it arranges for succession. The LSBit of
552 // responsibility for progress and succession lies with that other thread.
554 // operations are cheap. That is, repeated Unpark()ing of the ONDECK thread
559 // then progress is known to have occurred as that means the thread associated
560 // with "w" acquired the lock. In that case this thread need take no further
572 // Some other thread acquired the lock in the window since this
573 // thread released it. Succession is now that thread's responsibility.
578 // Slow-path exit - this thread must ensure succession and progress.
584 // Unlike a normal lock, however, the exiting thread "locks" OnDeck,
585 // picks a successor and marks that thread as OnDeck. That successor
586 // thread will then clear OnDeck once it eventually acquires the outer lock.
594 // Once OnDeck, a thread stays OnDeck until it acquires the lock.
595 // For a given lock there is at most OnDeck thread at any one instant.
608 // thread acquired the lock while this thread was arranging succession.
610 // for unpark()ing the OnDeck thread to the current or subsequent owners
611 // That is, the new owner is responsible for unparking the OnDeck thread.
634 // From the perspective of this thread, EntryList is stable and
644 // Note too, that it's safe for this thread to traverse the cxq
650 // or perhaps sort by thread priority. See the comments in
661 // A thread could have added itself to cxq since this thread previously checked.
669 // For instance, while this thread T1 held OnDeck, some other thread T2 might
670 // acquire the outer lock. Another thread T3 might try to acquire the outer
672 // outer lock, but skips succession as this thread T1 still holds OnDeck.
677 // that implies some other thread forced succession.
691 // Transfer one thread from the WaitSet to the EntryList or cxq.
716 // Experimental code ... light up the wakee in the hope that this thread (the owner)
755 // But if a thread in wait() encounters a timeout it will need to dequeue itself
757 // as the ParkEvent -- which serves as a proxy for the thread -- can't reside
758 // on both the WaitSet and the EntryList|cxq at the same time.. That is, a thread
764 // thread class. The WaitSet would be composed of WaitEvents. Only the
765 // owner of the outer lock would manipulate the WaitSet. A thread in wait()
768 // there would be no WaitLock. A thread in in wait() would enqueue its WaitEvent
785 // We call IUnlock (RelaxAssert=true) as a thread T1 might
788 // Some other thread T2 acquires the lock, and calls notify(), moving
791 // IUnlock() call a thread should _never find itself on the EntryList
866 // by a Java thread while it is blocked at a safepoint but before it has
868 // VM thread during a safepoint to avoid deadlocks. Alternatively, one should
877 // as follows. Currently, a thread might (a) while TBIVM, call pthread_mutex_lock
883 // VM thread to logically acquire locks that had already be physically locked by mutators
884 // but where mutators were known blocked by the reentry thread state transition.
924 // a java thread has locked the lock but has not entered the
932 // Try a brief spin to avoid passing thru thread state transition ...
955 // thread state set to be in VM, the safepoint synchronization code will deadlock!
969 // Returns true if thread succeceed [sic] in grabbing the lock, otherwise false.
974 // assert(!thread->is_inside_signal_handler(), "don't lock inside signal handler");
978 // In that case the VM thread can safely grab the lock.
1018 // Since the caller might be a foreign thread, we don't necessarily have a Thread.MutexEvent
1020 // we encounter contention. That ParkEvent remains associated with the thread
1038 _owner = ThreadLocalStorage::thread();
1046 // The ParkEvent remains associated with this thread until
1047 // the time the thread manages to acquire the lock.
1058 // At any given time there is at most one ondeck thread.
1060 // Only the OnDeck thread can try to acquire -- contended for -- the lock.
1131 // while we were waiting another thread suspended us. We don't
1133 // would surprise the thread that suspended us.
1201 st->print(" - owner thread: " PTR_FORMAT, _owner);
1269 // to track the lock-set of the thread and test for rank violations that
1285 // the thread is acquiring this lock
1288 assert(_owner == NULL, "setting the owner thread of an already owned mutex");
1301 // that the thread holds and m2 is the mutex the thread is trying
1329 // the thread is releasing this lock
1334 assert(old_owner != NULL, "removing the owner thread of an unowned mutex");
1335 assert(old_owner == Thread::current(), "removing the owner thread of an unowned mutex");
1365 void Monitor::check_prelock_state(Thread *thread) {
1366 assert((!thread->is_Java_thread() || ((JavaThread *)thread)->thread_state() == _thread_in_vm)
1367 || rank() == Mutex::special, "wrong thread state for using locks");
1369 if (thread->is_VM_thread() && !allow_vm_block()) {
1370 fatal(err_msg("VM thread using lock %s (not allowed to block on)",
1374 thread->check_for_valid_safepoint_state(false);)
1378 void Monitor::check_block_state(Thread *thread) {
1379 if (!_allow_vm_block && thread->is_VM_thread()) {
1380 warning("VM thread blocked on lock");
1384 assert(_owner != thread, "deadlock: blocking on monitor owned by current thread");