* state: BLOCKED, WAITING, or TIMED_WAITING.
   */
  void waitForThreadToEnterWaitState(Thread thread, long timeoutMillis) {
    long startTime = System.nanoTime();
    for (; ; ) {
      Thread.State s = thread.getState();
      if (s == Thread.State.BLOCKED || s == Thread.State.WAITING || s == Thread.State.TIMED_WAITING)
        return;

   *
   * @throws InterruptedException if interrupted while waiting
   */
  public void enterInterruptibly() throws InterruptedException {
    lock.lockInterruptibly();
  }

  /**
   * Enters this monitor. Blocks at most the given time, and may be interrupted.
   *
   * @return whether the monitor was entered
   * @throws InterruptedException if interrupted while waiting
   */

        assertTrue(aa.compareAndSet(i, prev, x));
        assertBitEquals(x, aa.get(i));
        prev = x;
      }
    }
  }

  /** compareAndSet in one thread enables another waiting for value to succeed */
  public void testCompareAndSetInMultipleThreads() throws InterruptedException {
    final AtomicDoubleArray a = new AtomicDoubleArray(1);
    a.set(0, 1.0);
    Thread t =

        assertTrue(aa.compareAndSet(i, prev, x));
        assertBitEquals(x, aa.get(i));
        prev = x;
      }
    }
  }

  /** compareAndSet in one thread enables another waiting for value to succeed */
  public void testCompareAndSetInMultipleThreads() throws InterruptedException {
    final AtomicDoubleArray a = new AtomicDoubleArray(1);
    a.set(0, 1.0);
    Thread t =

 *
 * <pre>
 * Thread1: acquire(LockA) --X acquire(LockB)
 * Thread2: acquire(LockB) --X acquire(LockA)
 * </pre>
 *
 * <p>Neither thread will progress because each is waiting for the other. In more complex
 * applications, cycles can arise from interactions among more than 2 locks:
 *
 * <pre>
 * Thread1: acquire(LockA) --X acquire(LockB)
 * Thread2: acquire(LockB) --X acquire(LockC)
 * ...

   * state: BLOCKED, WAITING, or TIMED_WAITING.
   */
  void waitForThreadToEnterWaitState(Thread thread, long timeoutMillis) {
    long startTime = System.nanoTime();
    for (; ; ) {
      Thread.State s = thread.getState();
      if (s == Thread.State.BLOCKED || s == Thread.State.WAITING || s == Thread.State.TIMED_WAITING)
        return;

 * ordinary tests.
 *
 * <p>Failure of the expected event to occur within an implementation-defined "reasonable" time
 * period or an interrupt while waiting for the expected event will result in a {@link
 * RuntimeException}.
 *
 * <p>Here's an example that tests a {@code finalize} method:
 *
 * <pre>{@code
 * final CountDownLatch latch = new CountDownLatch(1);

        assertThrows(
            TimeoutException.class,
            () -> service.startAsync().awaitRunning(1, TimeUnit.MILLISECONDS));
    assertThat(e)
        .hasMessageThat()
        .isEqualTo("Timed out waiting for Foo [STARTING] to reach the RUNNING state.");
  }

  private class FakeService extends AbstractExecutionThreadService implements TearDown {

   *
   * TODO(b/218700094): Does this matter to prod users, or is it just a feature of our testing
   * environment? If the latter, maybe write a custom Executor that avoids failing the test when it
   * sees an Error?
   */
  @AndroidIncompatible
  public void testTaskThrowsError() throws Exception {
    class MyError extends Error {}
    final CyclicBarrier barrier = new CyclicBarrier(2);

    // being resumed. To avoid a flake in this scenario, calculate how long that thread actually
    // waited and assert based on that time. Empirically, the race where the thread ends up waiting
    // for 5.5 seconds happens about 2% of the time.
    boolean longWait = TimeUnit.NANOSECONDS.toSeconds(thread.timeSpentBlocked) >= 5;