Although it's locked during async GC, the thread queue is not locked during
synchronous GC. This needs to be done because scanThreads() during GC needs
the lock, and as that's done with scheduling locked we can't let there be any
question that the GC-ing thread will get the lock. Not doing this causes a
presumably rare race condition, but one that would be quite disasterous if it
happens. In the race scenario, some other thread is holding the queue lock,
say because it is creating another thread or enumerating threads. It gets
scheduled out, and a thread that runs while it is out does a synchronous GC.
With the scheduler locked the GC-ing thread tries to get the queue lock which
is owned by the first thread. Green threads scheduling says that rather than
deadlock, we quietly let another thread run. This could cause GC to have an
inconsistent picture of the world, so it could break things in mysterious ways.

It's not known with certainty that this scenario can actually happen, and if it
can it can't be frequent. Given the easy fix it is a clearly unacceptable risk.