Details

Description

Under the situation of concurrent requires, if the first require exits with an Exception (that means the feature is not marked as already required), second and third requires by Threads runs parallel even if both have a lock. It's because we remove the lock from pool at the Exception.

Fixed at master. jruby-1_6 is safe because JRUBY-3194 and related fixes are not backported.

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
Thread.
Way to fix in other impls.
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.

Hiroshi Nakamura
added a comment - 16/Dec/11 12:03 AM Fixed at master. jruby-1_6 is safe because JRUBY-3194 and related fixes are not backported.
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
Thread.
Way to fix in other impls.
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.

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
Thread.
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.

Hiroshi Nakamura
added a comment - 16/Dec/11 1:49 AM The previous fix was incomplete. Updated.
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
Thread.
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.