Got now a full fledged gdb. Thread #1 loops infinitely in the "while (_Py_atomic_load_relaxed(&gil_locked))" loop in take_gil(). Thread #2 is stuck in the MUTEX_LOCK(gil_mutex) statement in drop_gil() as can be seen by setting a breakpoint at the following line and seeing that this breakpoint is never hit.

Setting gil_interval to 10 (from the initial value of 1) from gdb, allows the test to pass.

With this patch of PyCOND_TIMEDWAIT():

  diff -r eee959fee5f5 Python/condvar.h
  --- a/Python/condvar.h	Sat May 07 21:13:50 2016 +0300
  +++ b/Python/condvar.h	Mon May 16 15:52:49 2016 +0200
  @@ -99,6 +99,7 @@
       PyCOND_ADD_MICROSECONDS(deadline, us);
       ts.tv_sec = deadline.tv_sec;
       ts.tv_nsec = deadline.tv_usec * 1000;
  +    PyCOND_GETTIMEOFDAY(&deadline);

and a breakpoint set on pthread_cond_timedwait(). When this breakpoint is hit, there is 20 usec  elapsed time instead of the value of 1 (as requested by 'us') between ts and deadline as shown here:

  (gdb) p ts
  $1 = {tv_sec = 1463407197, tv_nsec = 468546000}
  (gdb) p deadline
  $2 = {tv_sec = 1463407197, tv_usec = 468566}

And when iterating the loop, the measured elapsed times are: 20, 12, 12, 11, 11, 11.

Clearly, the ts date is in the past when pthread_cond_timedwait() is called, and the function returns immediately without releasing the mutex. This is the expected behavior[1].

[1] http://linux.die.net/man/3/pthread_cond_wait