I think your characterization of sched_yield() is a bit off. The man page is clear:
"sched_yield() causes the calling thread to relinquish the CPU. The thread is moved to the end of the queue for its static priority and a new thread gets to run."
and
"If the calling thread is the only thread in the highest priority list at that time, it will continue to run after a call to sched_yield()."
In particular, it does not say "I’m not actually waiting for anything visible to the scheduler and, um, run me again soon maybe?".
So assuming that the threads are running at some relatively high priority, I'm struggling to see how delays on the order of 60ms could arise.
EDIT: reading further:
"sched_yield() is intended for use with real-time scheduling policies (i.e., SCHED_FIFO or SCHED_RR). Use of sched_yield() with nondeterministic scheduling policies such as SCHED_OTHER is unspecified and very likely means your application design is broken."
So maybe that's it.
There was a half-baked design for locking that kind of worked 20 years ago: try to acquire the spinlock and, if it’s contended, yield. On a single CPU, that probably means that the lock holder gets to run, and if they drop the lock quickly, then the yielding thread will (on an otherwise mostly idle system) get to run soon.
This was a dubious design 20 years ago, although, admittedly, OS lockout primitives were worse back then. But now, with multiple CPUs on a system, the whole scheme falls apart — the lock holder might be on a different CPU and yield() has no effect on how quickly the lock is released.
So, in most cases, yield() really does mean “I don’t know what I’m doing, but I don’t want to run right now.” Anything the kernel does in response is, at best, a wild guess.
So it is no surprise that latencies are high, because a yielded thread has to wait for absolutely every other thread in the system before it gets a chance to run.
So this is measuring a mess of a few things:
For mutexes (assuming all the implementations actually make syscalls for unlocking), this has something to do with how long it takes for the scheduler to activate the waiter and run it, plus how long the scheduler waits because the system is doing something else or it wants to try to avoid bouncing a task between CPUs.
For anything that does not involve the kernel in unlocking, this is really just a measurement of the pauses in execution of long-running threads that continuously hog the CPU. If the thread is also calling sched_yield(), the results are erratic, since sched_yield() more or less means “I don’t want to run now, but I’m not actually waiting for anything visible to the scheduler and, um, run me again soon maybe?” This is almost always the wrong solution. Other than that, this test has essentially nothing to do with which spinlock is in use, unless the spinlock itself wastes time failing to figure out that it’s ready.
From old memory, the Windows scheduler is (was?) mostly based on per-thread priorities, highest priority wins, where the priorities are occasionally automatically adjusted. So, if you set a high-ish priority, you get to hog the CPU. In contrast, Linux tries quite hard not to let normal (non-RT) threads hog the CPU, so a thread that effectively runs continuously measuring pauses will detect significant pauses in which Linux decides that the rest of the system deserves to run too.