[ruby-dev:45355] Re: 非同期割り込みに対する対処案（日本語版）

遠藤です。

2012-03-13 Urabe Shyouhei <[e-mail]>:
> On 2012年03月12日 21:00, Yusuke Endoh wrote:
>> もっと細かいことを言うと、POSIX thread では mutex のロック待ちは
>> ブロックしうるけれど cancellation point になっていません。
>> その理由は、推測ですが
>>
>>   - mutex のロックで割りこまれるようではプログラムを書くのが難しい
>>   - cancellation point に関係なく、mutex はロック内の処理を一瞬で
>>     終了することが求められていて、ロックで「ブロック」するほど待つ
>>     ケースは想定されていない
>>
>> などかと思います。
>
> POSIXではキャンセルが起こるとただ処理が中断されるのではなくクリーンアップ
> ハンドラが動くことがあります。ここで、条件変数を待っているスレッドがキャン
> セルされた時にクリーンアップハンドラに突入すると、そのハンドラ内で条件変数
> が待っていたmuetxはロックされた状態で突入してくることになっています。した
> がってクリーンアップハンドラは常にmutexをロックしている前提で書いてよいこ
> とになっています。ところがmutexのキャンセルがOKということにすると、クリー
> ンアップハンドラはmutexがロックされているのか、ロックされていないのかよく
> わからないような感じで動くということになります。これは正しく書くのがとても
> 面倒です。
>
> といったことがpthread_cond_wait(3posix)のRATIONALEに書いてあります。


へー。これは知りませんでした。
POSIX thread を真似するなら気をつけた方がいいですね。


ただ、私が言ったのは「pthread_mutex_lock はブロックしうるけど
cancellation point じゃない」という話で、上とは別の話です。

http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_lock.html

は見たんですが、特に rationale は書いてないようでした。検索してみたら

http://www.mkssoftware.com/docs/man3/pthread_cancel.3.asp

pthread_mutex_lock() is not a cancellation point, although it may
block indefinitely; making pthread_mutex_lock() a cancellation point
would make writing correct cancellation handlers difficult, if not
impossible.

http://sourceware.org/pthreads-win32/manual/pthread_mutex_init.html

None of the mutex functions is a cancellation point, not even
pthread_mutex_lock, in spite of the fact that it can suspend a thread
for arbitrary durations. This way, the status of mutexes at
cancellation points is predictable, allowing cancellation handlers to
unlock precisely those mutexes that need to be unlocked before the
thread stops executing. Consequently, threads using deferred
cancellation should never hold a mutex for extended periods of time.

など、やはり「プログラムを書くのが難しくなりすぎるから」ということの
ようです。


いずれにせよ、かなり余談に近い話です。すみません。

-- 
Yusuke Endoh <[e-mail]>