Lines Matching full:lock
155 holding the thread list lock, it will prevent the GC or debugger from
157 section around the entire operation (enter critical, get lock, do stuff,
158 release lock, exit critical).
162 then gets blocked on the thread list lock knows that the thread it is
163 waiting for is also in a critical section, and will release the lock
178 above are followed you don't need to lock anything in the GC. The risk is
289 * We need to assign the threadId early so we can lock/notify
327 * Grab the suspend count global lock.
334 * this lock recursively. Doesn't work with "fast" pthread mutexes.
336 * This lock is always held for very brief periods, so as long as
343 * Release the suspend count global lock.
351 * Grab the thread list global lock.
354 * the shutdown is in progress, and somebody tries to grab the lock, they'll
359 * the lock. Nobody can suspend all threads without holding the thread list
360 * lock while they do it, so by definition there isn't a GC in progress.
364 * are required to grab the thread list lock before the thread suspend
365 * count lock. (See comment in DvmGlobals.)
367 * TODO: consider checking for suspend after acquiring the lock, and
394 * Try to lock the thread list.
397 * current thread holds the lock this will fail.
405 * Release the thread list global lock.
436 * Grab the "thread suspend" lock. This is required to prevent the
439 * If we fail to get the lock, somebody else is trying to suspend all
440 * threads -- including us. If we go to sleep on the lock we'll deadlock
460 * thread suspend lock. (We release before the broadcast,
464 * and the lock has been grabbed but the suspend counts
475 LOGI("threadid=%d ODD: want thread-suspend lock (%s:%s),"
483 /* give the lock-holder a chance to do some work */
487 LOGE("threadid=%d: couldn't get thread-suspend lock (%s:%s),"
500 * Release the "thread suspend" lock.
574 * acquiring the lock. We want to let them finish their business
579 * after acquiring the lock and back off, something we should consider.)
916 dvmInitMutex(&thread->invokeReq.lock);
1266 * We need to lock out other threads while we test and set the
1268 * if this thread has been started before. We use the thread list lock
1294 * Thread creation might take a while, so release the lock.
1324 * The new thread will lock the thread list, change its state to
1326 * on gDvm.threadStartCond (which uses the thread list lock). This
1328 * after we grab the thread list lock, or will be awakened from the
1352 * - lock thread list
1354 * - sleep on condition var (mutex = thread list lock) until child starts
1366 * - lock thread list
1394 * This would be protected by the thread list lock and set by a
1414 gDvm.nonDaemonThreadCount++; // guarded by thread list lock
1424 * We must hold the thread list lock before messing with another thread.
1480 * because the pthread_cond_wait below needs to reacquire a lock that
1483 * signaled, and suspend-all will grab the thread list lock and then
1485 * trying to get the lock.
1669 * Because we aren't holding a lock across the thread creation, it's
1672 * holding the thread list lock, the initial condition on the "while"
1786 * requires that we hold the thread list lock.
1831 * To deal with this, we transition to VMWAIT, pulse the heap lock,
1907 * worth putting effort into fixing. Need to hold a lock while
2142 gDvm.nonDaemonThreadCount--; // guarded by thread list lock
2172 * The thread list lock should be held before calling here -- it's not
2199 * The thread list lock should be held before calling here -- it's not
2259 * suspend count lock.
2277 * just long enough to try to grab the thread-suspend lock).
2410 * suspend-all, which implies that the suspend-all lock is held, or as
2528 * lock and suspend lock here (and we're not using recursive threads), and
2543 * Start by grabbing the thread suspend lock. If we can't get it, most
2547 * We keep the lock until all other threads are suspended.
2667 * lock while we issue the wakeup broadcast. It allows us to complete
2675 * thread-suspend lock.
2678 * lock, it times out after 3 seconds. If at some point the thread
2682 * was trying to acquire the lock, we would occasionally time out on
2687 * returns, because we're holding the thread-suspend-count lock, but the
2691 * the thread-suspend lock and grab the thread-suspend-count lock.
2695 * lock before releasing thread-suspend, since we're still following
2769 * the thread list lock before calling.
2803 * We can't hold a thread lock here or in the caller, because we could
2852 * Wait for wakeup signal, releasing lock. The act of releasing
2853 * and re-acquiring the lock provides the memory barriers we
2919 * grab suspend-count lock
2921 * release suspend-count lock
2927 * We can correct this by grabbing the suspend-count lock and
3017 * we will be touching invalid data. For safety, lock the thread list
3047 * Caller must hold the thread list lock.
3063 * Caller must hold the thread list lock.
3362 * If "grabLock" is true, we grab the thread lock list. This is important
3363 * to do unless the caller already holds the lock.
