HomeSort by relevance Sort by last modified time
    Searched refs:user_code_suspension_lock_ (Results 1 - 7 of 7) sorted by null

  /art/runtime/openjdkjvmti/
ti_thread.h 100 REQUIRES(!art::Locks::mutator_lock_, !art::Locks::user_code_suspension_lock_);
102 REQUIRES(!art::Locks::mutator_lock_, !art::Locks::user_code_suspension_lock_);
ti_thread.cc 313 REQUIRES(art::Locks::user_code_suspension_lock_) {
429 REQUIRES(!art::Locks::mutator_lock_, !art::Locks::user_code_suspension_lock_) {
445 // the user_code_suspension_lock_ due to a SuspendReason::kForUserCode. In this situation we
449 art::MutexLock ucsl_mu(self, *art::Locks::user_code_suspension_lock_);
706 // the user_code_suspension_lock_ due to a SuspendReason::kForUserCode. In this situation we
715 art::MutexLock mu(self, *art::Locks::user_code_suspension_lock_);
751 art::MutexLock mu(self, *art::Locks::user_code_suspension_lock_);
810 art::MutexLock mu(self, *art::Locks::user_code_suspension_lock_);
    [all...]
  /art/runtime/base/
mutex.h 585 static Mutex* user_code_suspension_lock_ ACQUIRED_AFTER(instrument_entrypoints_lock_);
622 static MutatorMutex* mutator_lock_ ACQUIRED_AFTER(user_code_suspension_lock_);
mutex.cc 71 Mutex* Locks::user_code_suspension_lock_ = nullptr; member in class:art::Locks
236 // We allow the thread to wait even if the user_code_suspension_lock_ is held so long as we
240 // SuspendReason::kForUserCode (which needs the user_code_suspension_lock_ to clear) this is
242 if (held_mutex == Locks::user_code_suspension_lock_ && level_ == kThreadSuspendCountLock) {
243 // No thread safety analysis is fine since we have both the user_code_suspension_lock_
    [all...]
  /art/runtime/
thread-inl.h 160 // Make sure that if we hold the user_code_suspension_lock_ we aren't suspending due to
169 << Locks::user_code_suspension_lock_->GetName() << "\"! Thread would never "
thread.h 232 Locks::user_code_suspension_lock_) {
    [all...]
thread.cc     [all...]

Completed in 69 milliseconds