Don't let tasks woken by completion callbacks spin on a preempted lock holder

[maleadt]

KernelAbstractions' benchmark bot still showed PoCL launches of 50–400 µs kernels getting 15–30% slower with cooperative waiting (JuliaGPU/KernelAbstractions.jl#813), much more than the one extra thread wake-up that completion callbacks cost. The cause turned out to be in signal_completion, and it's a classic lock-holder preemption problem.

signal_completion runs on the driver's thread (for PoCL, its dedicated callback thread). It takes the completion's spin lock, wakes the waiting task with notify, and then releases the lock. The woken task immediately takes the lock again (wait on a condition reacquires it before returning). If the OS runs the woken Julia thread on the same CPU as the driver's thread, the Julia thread preempts it while it still holds the lock. Julia's SpinLock never gives up the CPU, so the task spins until the OS happens to switch back. That's rare on an idle machine with spare cores. But PoCL runs kernels on the host's cores, and with as many PoCL workers as cores, a GitHub runner's 4 vCPUs for example, there's never a spare one.

perf on the launching thread, with KernelAbstractions launching ~1 ms kernels in a loop on 4 cores (POCL_MAX_PTHREAD_COUNT=4, pinned with taskset), shows where its time goes:

82.03%  julia  sys.so  [.] julia_lock_1409.2
        |--75.65%--lock (inlined)
        |          relockall; (inlined)
        |          #wait#392 (inlined)

Measured as the launching thread's CPU time per launch, which a loaded machine doesn't distort much:

~1 ms kernel, 4 PoCL workers on 4 cores	launching thread's CPU per launch
blocking clWaitForEvents	20–40 µs
cooperative_wait with callbacks, GPUToolbox 3.3.1	195–245 µs
same, with this PR	30–65 µs

That spinning takes a core away from the next kernel, which is where the slowdown came from. In one A/B run on 4 cores, a 1M-element saxpy took 108 µs with blocking waits and 194 µs with callbacks, and a ~1 ms compute-bound kernel 1040 µs versus 1254 µs. With this PR, the compute-bound kernel took 1026 µs against 1018 µs blocking. (The machine was shared and heavily loaded, so only compare numbers within one run.)

The fix is a spin lock whose waiters give up their CPU (sched_yield, or SwitchToThread on Windows) after spinning briefly, so the preempted driver thread gets to run and release the lock. It wraps Threads.SpinLock, and the completion uses it through a plain GenericCondition, so the wake-up protocol, including the handling of interrupts, is the same as before.

I first tried keeping the spin lock and waking the task only after releasing it. That fixes the problem too, but needs GenericCondition internals: its wait queue holds tasks up to 1.13, and Base.WaitEntry1 objects on nightly. It also opens a small window in which a waiter that is interrupted gets scheduled again later, spuriously.

The new tests let a foreign thread hold the lock (sleeping) after notifying the waiter, and contend for it while a Julia thread holds it and runs the GC. They check that both sides finish, rather than timing anything. The test suite passes on Julia 1.10, 1.12, 1.13 and nightly. sol reviewed the lock implementation (AbstractLock fallbacks for GenericCondition from 1.10 to nightly, finalizer inhibition and GC safepoints on a foreign thread, the Windows ccall).

This bumps the version to 3.3.2.