Another possibility might be to not use the Windows timeout clock, at least not for short timeouts.  The following shows that tk does about 970 1 millesecond timeouts in 1 second (on my machine).
---
import tkinter as tk

root = tk.Tk()
cbid = None
cbcount = 0

def cb():
    global cbid, cbcount
    cbcount += 1
    cbid = root.after(1, cb)

def cbcancel():
    print(cbcount)
    root.after_cancel(cbid)

root.after(1000, cbcancel)
cbid = root.after(1, cb)
root.mainloop()
---

Here is a proof-of-concept queue-get-with-timeout function with sub-millesecond resolution.
---
import tkinter as tk
from queue import Queue, Empty
from time import perf_counter

q = Queue()
fails = 0
value = '<raise Empty>'

def qcb():
    try:
        global value
        value = q.get(block=False)
    except Empty:
        global fails
        fails += 1
        if perf_counter() < stop:
            root.after(0, qcb)
            return
    root.destroy()

def qget_to(timeout):
    global root, stop
    root = tk.Tk()
    root.withdraw()
    stop = perf_counter() + timeout
    qid = root.after(0, qcb)
    #q.put(1)
    root.mainloop()
    print('failures:', fails, 'value:', value)

qget_to(.001)
---

With the put commented out, there are 27 fails (on my machine).  When a value is already available, there are none.  The loop could be parameterized to repeatedly call the no-block version of any similar function.  Large enough time-outs could be partially fulfilled using the system timeout function.