Project

General

Profile

Actions

Feature #7505

closed

Mutex#owned? メソッドの新設

Added by kosaki (Motohiro KOSAKI) over 11 years ago. Updated over 11 years ago.

Status:
Closed
Target version:
[ruby-dev:46697]

Description

以下のようなプログラムがあったとします。

Thread.async_interrupt_timing(Object => :on_blocking) {
begin
  mutex = Mutex.new
mutex.synchronize {
sleep 1
condvar.wait mutex
 }
ensure
リソース解放したい
end
}

mutex.synchronizeの中でCtrl-cを押したとき、割り込まれる可能性のある箇所が三ヶ所あります

  1. sleep
  2. mutex.sleep の中のnative_sleep(condvar.signal 待ち)
  3. mutex.sleep の中のrb_mutex_lock(condvar.signalで起床されたが、mutexを別スレッドが使用中だったためmutex待ち)

このとき、1と2はmutexを持ったままensureに入りますが、3はmutexを持たずにensureに入ってきます。さらに悪いことに2と3はRubyからは同じメソッド内にあるため、rubyレベルで workaroundをもうけることができません。

リソースを正しく解放する手段が「ない」というのは問題であるので、Mutex#owned? メソッドの新設を提案します。これはMutex#locked? とは異なり自分がロックを持っているときのみtrueを返します

パッチは以下

https://gist.github.com/4195632

以下余談、POSIXだと、pthread_cond_waitはキャンセレーションポイントではないし、なにがあろうともMutexをlockし終わってから関数を抜けてくるのでこういう問題はありません。これに揃えるという手もあるのですが、そうすると別スレッドがロックを持ったままでいるとCtrl-Cが効かなくなるのでakrさんの好みにはあわなさそう。


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #6762: Control interrupt timingClosedko1 (Koichi Sasada)07/21/2012Actions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0