[ruby-core:47525] [ruby-trunk - Bug #6174] Fix collision of ConditionVariable#wait timeout and #signal (+ other cosmetic changes)

Issue #6174 has been updated by funny_falcon (Yura Sokolov).


> + serialize.wait{ thread.run }

This could be

+ serialize.wait{ }

Test is failing as well, so that, step 4 doesn't matter.
In fact, step 4 runs before step 2 in every run, you could easily check it by putting "puts", so that
thread.run wakes up sub thread at the beginning, not at the condvar.wait !!!!

Then steps are looks like:

1. main thread wait at serialize.wait
2. sub thread wake main thread up by serialize signal
3. sub thread wait at condvar.wait(mutex, 0.001)
5. main thread take 'mutex'
6. main thread sleep 0.01 seconds (imitating some work).
7. sub thread tries to wake up, so that it should not be present in waiters.
   But he can't wake up because it can't take a 'mutex'.
7. main thread inspect condvar.waiters and it found sub thread.

I cann't understand, why "main thread shouldn't take a mutex"? In real application it could be very other thread, not main.
Holding mutex by main thread were intentionally to expose this race. Race could happen without it, but it would be hard to catch.

I see, that callback should be wrapped in ensure inside of mutex.sleep . Thank you for this point, I'll try to fix it.


----------------------------------------
Bug #6174: Fix collision of ConditionVariable#wait timeout and #signal (+ other cosmetic changes)
https://bugs.ruby-lang.org/issues/6174#change-29298

Author: funny_falcon (Yura Sokolov)
Status: Rejected
Priority: Normal
Assignee: kosaki (Motohiro KOSAKI)
Category: lib
Target version: 2.0.0
ruby -v: ruby 2.0.0dev (2012-03-17 trunk 35075) [i686-linux]


1. Currently, when Thread wakes on timeout, it could not remove itself from ConditionVariable waiters until it acquires lock.
So that, when ConditionVariable#signal is called, it will try to wakeup
such thread, instead of some one else.
https://github.com/funny-falcon/ruby/commit/24a9b6112477b2107ac9a19d0189a11fb97aa891
https://github.com/funny-falcon/ruby/commit/24a9b6112477b2107ac9a19d0189a11fb97aa891.patch

Simple way to avoid it, is to allow Mutex#sleep to recieve a block, which will be called right after Thread will awake, but before Mutex will be tried to lock
https://github.com/funny-falcon/ruby/commit/9e9157c5318926331dbe883416b69d38a58fea5d
https://github.com/funny-falcon/ruby/commit/9e9157c5318926331dbe883416b69d38a58fea5d.patch

2. Since MatzRuby use GVL for thread isolation, and native method could not be interrupted (unless it will), we could remove couple of calles to Mutex#synchronize
https://github.com/funny-falcon/ruby/commit/a9ad8d274b96f14519643fc63327394f72b83516
https://github.com/funny-falcon/ruby/commit/a9ad8d274b96f14519643fc63327394f72b83516.patch

3. Usage of hash with `compare_by_identity` allows remove call to Array#include? in a Queue. Also it allows to remove other call Mutex#synchronize from ConditionVariable#wait in case when we rely on GVL.
https://github.com/funny-falcon/ruby/commit/0da1887a04f7a0e4f9289d2167c2a6d0073651e1
https://github.com/funny-falcon/ruby/commit/0da1887a04f7a0e4f9289d2167c2a6d0073651e1.patch

4. And cosmetic changes to SizedQueue
https://github.com/funny-falcon/ruby/commit/60ed97557c8178bc78edf670f3d53d761e627bf0
https://github.com/funny-falcon/ruby/commit/60ed97557c8178bc78edf670f3d53d761e627bf0.patch

Pull request at once:
https://github.com/ruby/ruby/pull/104
https://github.com/ruby/ruby/pull/104.diff
https://github.com/ruby/ruby/pull/104.patch


-- 
http://bugs.ruby-lang.org/