Changing the system timer resolution doesn't appear to help, given the current design combined with what looks like a bug in Windows (at least in Windows 10). We can set the system clock resolution below a millisecond via NtSetTimerResolution. I tested at 0.4882 ms, which allowed sleeping for 0.5 ms via NtDelayExectution. (NT interval resolution is 100 ns, nominally). But Python's threading Lock timeout is still limited to about 15-16 ms. I'd expect 1 ms resolution given we're ultimately calling WaitForSingleObjectEx via PyCOND_TIMEDWAIT -> _PyCOND_WAIT_MS.

It appears the problem is that GetTickCount[64] continues to increment by 15.625 ms (i.e. by 15 to 16), which looks like a bug to me, but may be a compatibility behavior. We use the tick count in EnterNonRecursiveMutex in the following block of code:

    } else if (milliseconds != 0) {
        /* wait at least until the target */
        DWORD now, target = GetTickCount() + milliseconds;
        while (mutex->locked) {
            if (PyCOND_TIMEDWAIT(&mutex->cv, &mutex->cs, (long long)milliseconds*1000) < 0) {
                result = WAIT_FAILED;
                break;
            }
            now = GetTickCount();
            if (target <= now)
                break;
            milliseconds = target-now;
        }
    }