Issue #7505 has been reported by kosaki (Motohiro KOSAKI).
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by tarui (Masaya T.).
多分、こういう事だろうとおもうのですが、
mutex=Mutex.new
Thread.new{
mutex.synchronize{
begin
sleep 1
mutex.sleep
ensure
リソース解放
end
}
}
mutex.syncronize{
sleep 10
}
mutex.sleepでmutexを手放している間にC-cがされてmutexを確保しようとするが確保できなかったとして、
そのmutexを確保しているThreadも死なないと行けないのでいずれmutexは解放されて、
mutex.sleepの方でmutexを取れるんじゃ無いでしょうか？
なので、mutexを取れるまで待つように修正する方針を押したいと思います。
つまり、1,2,3いずれの例でもmutexを保持してensureに入るようにしたい。
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by kosaki (Motohiro KOSAKI).
樽井さんの例はもっと危険で mutexがunlockしたまま例外で抜けてきて synchronized抜けるときにもう一度
unlockしちゃうので、二重unlockでThreadErrorになっちゃいますね
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by tarui (Masaya T.).
それは小崎さんの3の場合でも同じだと思うけど、
そう言う点からしても、例外で抜ける場合でmutexのlockとらないでunlockしたままとかおかしいですよね。
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by tarui (Masaya T.).
＞> なので、mutexを取れるまで待つように修正する方針を押したいと思います。
＞これは個人的には賛成しますが、別チケットにすることを提案します。
Mutex#owned? の話でしたね。すいません。
これ自体には賛成です。
ただ、これでどうして元の課題が救えるのか分かりませんでした。
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by kosaki (Motohiro KOSAKI).
なので、mutexを取れるまで待つように修正する方針を押したいと思います。
これは個人的には賛成しますが、別チケットにすることを提案します。
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。
Issue #7505 has been updated by kosaki (Motohiro KOSAKI).
Status changed from Open to Assigned
Assignee set to kosaki (Motohiro KOSAKI)
Feature #7505: Mutex#owned? メソッドの新設
Author: kosaki (Motohiro KOSAKI)
Status: Assigned
Priority: Normal
Assignee: kosaki (Motohiro KOSAKI)
Category: core
Target version: next minor
以下のようなプログラムがあったとします。
Thread.async_interrupt_timing(Object => :on_blocking) {
begin
mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
}
ensure
リソース解放したい
end
}
mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります
- sleep
- mutex.sleep の中のnative_sleep（condvar.signal 待ち）
-
mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち）
このとき、１と２はmutexを持ったままensureに入りますが、３はmutexを持たずにensureに入ってきます。さらに悪いことに２と３はRubyからは同じメソッド内にあるため、rubyレベルで
workaroundをもうけることができません。
リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned?
メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します
パッチは以下
以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。