Actions
Bug #10076
closed2nd thread can't get mutex even though 1st thread released it (race)
Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.1.2p95 (2014-05-08 revision 45877) [i686-linux]
Backport:
Description
require 'thread'
m = Mutex.new
Thread.abort_on_exception = true
Thread.new {
loop {
m.synchronize {
puts 'got mutex in thread'
sleep 0.1
}
}
}
loop {
m.synchronize {
puts 'got mutex in loop'
sleep 1
}
# Without sleep, the thread above has no chance of getting the mutex.
#sleep 0.1
}
Files
Updated by ledestin (Dmitry Maksyoma) almost 10 years ago
- File monitor-test monitor-test added
Attaching source code with reproduced problem.
Updated by nobu (Nobuyoshi Nakada) almost 10 years ago
- Description updated (diff)
Thread fairness issue?
Checking interrupts seems to help it, but not sure.
diff --git a/thread.c b/thread.c
index 682e05f..6f67df6 100644
--- a/thread.c
+++ b/thread.c
@@ -4528,11 +4528,15 @@ rb_mutex_synchronize(VALUE mutex, VALUE (*func)(VALUE arg), VALUE arg)
static VALUE
rb_mutex_synchronize_m(VALUE self, VALUE args)
{
+ VALUE ret;
+
if (!rb_block_given_p()) {
rb_raise(rb_eThreadError, "must be called with a block");
}
- return rb_mutex_synchronize(self, rb_yield, Qundef);
+ ret = rb_mutex_synchronize(self, rb_yield, Qundef);
+ RUBY_VM_CHECK_INTS(GET_THREAD());
+ return ret;
}
void rb_mutex_allow_trap(VALUE self, int val)
Updated by naruse (Yui NARUSE) almost 10 years ago
- Status changed from Open to Feedback
Updated by kosaki (Motohiro KOSAKI) almost 10 years ago
Your code is very artifactual and the patch of comment #2 reduce a performance of normal case. So, until someone provide a real usecase, I don't take it.
Updated by jeremyevans0 (Jeremy Evans) almost 5 years ago
- Status changed from Feedback to Closed
Actions
Like0
Like0Like0Like0Like0Like0