Add a gc-safe sleeping mutex

[pchintalapudi]

Threads that wait for the codegen lock should really sleep when it isn't available, since codegen often takes a nontrivial amount of time to complete. Therefore we introduce a sleeping mutex that cooperates with the GC to replace the spin mutex.

Sleeping lock implementation mostly stolen from here: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189755

If we run on an example that forces 5 threads to attempt to acquire the codegen lock at the same time:

Before:

After:

[vchuravy]

So one question I have is, does it make sense to use a Julia scheduler integrated lock? These threads could do useful work, instead of being blocked on codegen.

[pchintalapudi]

A scheduler integrated lock would be nice, but I think this sleeping lock is at least a net positive in all aspects compared to the spin lock. Depending on how much of the scheduler is implemented in Julia vs C, it may even be illegal to yield out of codegen to another task (if the scheduler itself needs to take any lock besides the codegen lock, we could end up in a deadlock).

[gbaraldi]

While talking with @vtjnash he mentioned to me that maybe what we should do here is something like webkits WTF::Lock or rusts https://docs.rs/parking_lot_core/latest/parking_lot_core/ https://webkit.org/blog/6161/locking-in-webkit/.

[pchintalapudi]

Yeah I implemented something similar to WTF::Lock here, except instead of a full-blown hash table I just use an array with hardcoded length, and accept a few extra spurious wakeups and collisions over the same cond/mutex. If we decide that perhaps the codegen lock is really the only kind of lock that should be sleeping, then we can just make jl_sleep_mutex_t contain a uv_mutex_t and not bother with the array either.