JRUBY-6278: Double require bug in the handling of concurrent requires
Try to re-acquire the lock if the locked object is not in the pool after
locking. The locked object may removed from the pool by precedent
How other impls fixes it.
CRuby: check if another Thread is trying to acquire the lock before
removing the lock from the pool. GVL saves everything.
Rubinius: Get the object from the pool, then tries to lock. I think
there's a race here.
The difference from the previous fix (6c67f35b) is the existence check
of the pool after acquiring the lock. The previous fix checks if it's
null or not, but under heavy concurrent situation, later Threads may
update the lock in the pool. So we need to check if it's the same
object or not.