マルチスレッドプログラミング相談室その8

マルチスレッドプログラミング相談室その8at TECH

マルチスレッドプログラミング相談室その8 - 暇つぶし2ch■コピペモード
□スレを通常表示
□オプションモード
□このｽﾚｯﾄﾞのURL
■項目テキスト

50:デフォルトの名無しさん
 09/09/23 11:50:28 
Win32のmutexはプロセスレベルじゃなくてシステムレベル？ 
で排他してるから重いのはしょうがないかと・・

51:デフォルトの名無しさん
 09/09/23 11:54:36 
>>50 
ですな。 
というか、一般的に言う "mutex" に相当するものを、 
Win32では "Critical Section" と呼んでいるから 
混乱を招いているだけなんだけど。

52:デフォルトの名無しさん
 09/09/23 11:58:17 
W32はCSもMutexも両方Mutexで特性が違うと考えるのが自然

53:デフォルトの名無しさん
 09/09/23 12:58:23 
プロセスレベルで排他するからじゃなくて、 
カーネルオブジェクトなのが原因なんじゃね？

54:デフォルトの名無しさん
 09/09/23 13:24:11 
目的がそうだからしょうがない

55:35
 09/09/23 13:27:30 
>>45 
>てことで、>40にも書いたようにJavaのBlockingQueueの実装クラスが 
>wait-freeでもlock-freeでもないのは、手抜きしているわけではなく 
>そのように実装するのが不可能だからだ。 
 
明解な説明です。理解できました。 
 
>だからそれは "wait-free" って言葉の意味を誤解してるって。 
>"wait-free" の wait とは、モニタ同期のwait()操作とかとは別物。 
 
そのモニタ同期のwaiti()操作をイメージしていました。間違っていたんですね。 
でわ、wait-freeの意味は、単純に「待ちが発生しない」へ改めます。 
となると、lock-freeの意味も「待ちが発生する」に変わります。 
ただし、どちらも「lock操作は不要」という特徴は共通している、と。 
これでスッキリしました。 
 
実は>>13,14,23のカキコ主だったのですが、lock-freeでは生産者-消費者モデルを 
実現できない(畑違いである)ことが分かったので、次はwait-freeをと考えていましたが、 
それも同様に誤解であることが理解できました。lock-free/wait-freeはスレッド間同期を 
実現するプリミティブではない。それを実現するには、(lock操作を伴う)mutexや 
モニタ同期(signal/wait)などを導入する必要がある、と。 
 
lock-free/wait-freeの使い方について、ここ数日で急速にイメージが掴めてきた感覚です。 
たいへんありがとうございました。>>all(特に>>15,32,40,45) 
後は、Javaだけでなく、C/C++でも利用できる一般的なlock-free/wait-freeの実装技法が 
確立し、標準ライブラリとして仕様化されることを願っています。

次ページ