[#29911] [Bug #3231] Digest Does Not Build — Charlie Savage <redmine@...>

Bug #3231: Digest Does Not Build

19 messages 2010/05/01

[#29920] [Feature #3232] Loops (while/until) should return last statement value if any, like if/unless — Benoit Daloze <redmine@...>

Feature #3232: Loops (while/until) should return last statement value if any, like if/unless

9 messages 2010/05/01

[#29997] years in Time.utc — Xavier Noria <fxn@...>

Does anyone have a precise statement about the years supported by

13 messages 2010/05/04

[#30010] [Bug #3248] extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly — Luis Lavena <redmine@...>

Bug #3248: extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly

9 messages 2010/05/05

[#30226] [Bug #3288] Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88 — Szymon Jeż <redmine@...>

Bug #3288: Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88

10 messages 2010/05/13

[#30358] tk doesn't startup well in doze — Roger Pack <rogerdpack2@...>

Currently with 1.9.x and tk 8.5,the following occurs

12 messages 2010/05/22

[ruby-core:29970] [Bug #3212] ConditionVariable may become inconsistent for interrupted threads

From: Sylvain Joyeux <redmine@...>
Date: 2010-05-03 12:17:25 UTC
List: ruby-core #29970
Issue #3212 has been updated by Sylvain Joyeux.


This is *not* about having spurious wakeups or not (I understood that my knowledge of pthreads is lower than yours, and I apologize for the noise). This is about maintaining class invariants, in this case: "threads that are listed in @waiters should be the threads waiting for the CV".

A few scenarios:

Scenario 1
----------
1) Thread 'a' gets a spurious wakeup
2) Thread 'a' gets back to wait() because it is in an until loop. @waiters contains 'a' two times.
3) Thread 'b' wakes 'a' up
4) Thread 'a' leaves the synchronization section. 'a' is still listed in @waiters (the bug I am reporting)
5) Later on, 'a' goes back to sleep (for whatever reason)
6) Thread 'b' calls CV#signal and wakes up 'a', since 'a' is still in @waiters

Scenario 2
----------
1) Thread 'a' gets a spurious wakeup
2) Thread 'a' gets back to sleep *not using CV#wait" (using mutex#sleep or Thread.sleep, for whatever reason)
3) Thread 'b' calls CV#signal, which wakes 'a' up since 'a' is still in the @waiters list.

In (3), 'a' was not waiting on the CV anymore. But 'b' called a#run anyway.

Scenario 3
----------
This is a modified version of Scenario (1)

1) Thread 'a' gets a spurious wakeup
2) Thread 'a' gets back to wait() because it is in an until loop. @waiters contains 'a' two times.
3) Thread 'b' wakes 'a' up
4) Thread 'a' leaves the synchronization section. 'a' is still listed in @waiters (the bug I am reporting)
5) Thread 'b' calls CV#signal and wakes up 'a', which does not wait for the CV anymore

I.e. CV#signal in (5) does *not* wake up anybody, which most likely will lead to a deadlock

----------------------------------------
http://redmine.ruby-lang.org/issues/show/3212

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

In This Thread