Correct, it uses an aggressive spinlock without fairness features for waiters like you'd see with a proper production-quality mutex. This makes it very efficient in the absence of contention (i.e. in trivial benchmarks) and extremely poorly behaved in times of contention.

I assumed they would spin for only a short period of time only then fallback to a real lock.

This is usually done to avoid blocking the thread before the end of it's time slice if there is a chance the lock would become available.

If instead they implement a pure spin loop with sleep I can see why it does not perform well.