[#44925] [Backport93 - Backport #5702][Open] backport r33935 — Yusuke Endoh <mame@...>

19 messages 2011/12/03

[#44940] Re: [ruby-cvs:41134] naruse:r33956 (trunk): Comment out tests which fails with GDBM-DBM compat mode. — Tanaka Akira <akr@...>

2011/12/6 <[email protected]>:

9 messages 2011/12/05
[#44941] Re: [ruby-cvs:41134] naruse:r33956 (trunk): Comment out tests which fails with GDBM-DBM compat mode. — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/05

2011年12月5日16:56 Tanaka Akira <[email protected]>:

[#44942] Re: [ruby-cvs:41134] naruse:r33956 (trunk): Comment out tests which fails with GDBM-DBM compat mode. — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/05

> おかしいな。gdbmは勝手にcreateフラグを立ててしまうので当該2つの

[#44985] [ruby-trunk - Bug #5757][Open] main threadがreadやselectで待っていると、^C でなかなか死なない — Yui NARUSE <naruse@...>

12 messages 2011/12/13

[#45021] [ruby-trunk - Bug #5786][Open] LoadError: cannot load such file -- openssl — Kazuhiro NISHIYAMA <redmine@...>

11 messages 2011/12/21

[#45057] [ruby-trunk - Feature #5820][Assigned] Merge Onigmo to Ruby 2.0 — Yui NARUSE <naruse@...>

21 messages 2011/12/28

[ruby-dev:45064] [ruby-trunk - Bug #5355] Sync_mにBug #5195やBug #5258と同様のバグ

From: Motohiro KOSAKI <kosaki.motohiro@...>
Date: 2011-12-30 08:18:27 UTC
List: ruby-dev #45064
Issue #5355 has been updated by Motohiro KOSAKI.


スレッドまわりは振ってくれていいですよ。ほかに誰も見てくれなさそうだし。ただあからさまに優先度低そうなやつは暇なときかリリース近いときしか作業できませぬ

----------------------------------------
Bug #5355: Sync_mにBug #5195やBug #5258と同様のバグ
https://bugs.ruby-lang.org/issues/5355

Author: Masaki Matsushita
Status: Open
Priority: Normal
Assignee: Motohiro KOSAKI
Category: lib
Target version: 2.0.0
ruby -v: ruby 1.9.4dev (2011-09-20 trunk 33301) [x86_64-linux]


=begin
Sync_mにもBug #5195やBug #5258と同様のバグがあります。

 require 'sync'
 
 class Foo; include Sync_m; end
 
 foo = Foo.new
 foo.sync_lock(:EX)
 
 t = Thread.new { foo.sync_lock(:EX) }
 
 nil until t.stop?
 p foo.sync_waiting
 
 t.wakeup
 
 nil until t.stop?
 p foo.sync_waiting

上記のコードを実行すると

 [#<Thread:0x00000001936858 sleep>]
 [#<Thread:0x00000001936858 sleep>, #<Thread:0x00000001936858 sleep>]
 
このように、起こされた際に@sync_waitingに再度Thread.currentをpushしてしまいます。
また、次のコードを実行すると、

 require 'sync'
 
 class Foo; include Sync_m; end
 
 foo = Foo.new
 foo.sync_lock(:SH)
 
 t = Thread.start do
 foo.sync_lock(:SH)
 foo.sync_lock(:EX)
 end
 
 nil until t.stop?
 p foo.sync_upgrade_waiting
 p foo.sync_waiting
 
 t.wakeup
 
 nil until t.stop?
 p foo.sync_upgrade_waiting
 p foo.sync_waiting

このような結果となります。

 [[#<Thread:0x000000015e04d8 sleep>, 1]]
 []
 [[#<Thread:0x000000015e04d8 sleep>, 1]]
 [#<Thread:0x000000015e04d8 sleep>]
 
複数のスレッドが共有ロックを保持している時にあるスレッドが共有ロックから排他ロックへ昇格しようとした場合、
共有ロックの開放を待つスレッドは@sync_upgrade_waitingにpushされますが、この状態からそのスレッドを起こすと、
@sync_upgrade_waitingではなく@sync_waitingにThread.currentがpushされます。

また、 http://redmine.ruby-lang.org/issues/5258#note-2 と同様の問題ですが、ロックの開放待ちで寝ているスレッドに例外を発生させると、
@waitingにpushされたスレッドはそのまま放置されてしまいます。

 require 'sync'
 
 class Foo; include Sync_m; end
 
 foo = Foo.new
 foo.sync_lock(:EX)
 
 t = Thread.new { foo.sync_lock(:EX) }
 
 nil until t.stop?
 p foo.sync_waiting
 t.raise
 nil while t.alive?
 p foo.sync_waiting
 
実行結果:

 [#<Thread:0x00000000e498f0 sleep>]
 [#<Thread:0x00000000e498f0 dead>]

以上の問題を解決するpatchを添付します。

=end


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

In This Thread