[過去ﾛｸﾞ]
マルチスレッドプログラミング相談室 その8 (1001ﾚｽ)
マルチスレッドプログラミング相談室 その8 http://peace.5ch.net/test/read.cgi/tech/1253521167/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
40: デフォルトの名無しさん [sage] 2009/09/23(水) 00:45:03 >>35 キューが空ならnullを返したり例外を投げたりすればいい。 たとえばJavaでは、要素が空のときにnullを返したりする Queue と、 要素が空のときに新たな要素が来るまで待機する操作がある BlockingQueue とが、 ちゃんと区別されている。 で、Queueにはwait-freeな実装クラス ConcurrentLinkedQueue があるけど、 BlockingQueueの実装クラスである LinkedBlockingQueue や ArrayBlockingQueue とかは wait-freeでもlock-freeでもない。 で、君が欲しいのは Queue なの? BlockingQueueなの? http://peace.5ch.net/test/read.cgi/tech/1253521167/40
43: 35 [sage] 2009/09/23(水) 06:49:21 >>40 レスありがトン。詳しい解説は、とても助かる。 欲しいのは、待機が可能なwait-free queueの実装クラスです。 この場合には、ConcurrentLinkedQueueでキューを生成し、 nullあるいは例外発生であればスレッドを(たとえばwait操作で)待機させるよう アプリケーション側で実装することになるのでしょうか？ スレッドを待機させる方法はwait操作以外にもいろいろあるから、 どの方法を選ぶかはアプリケーションにまかせる、という考え方になります。 wait-free queueの意味が「wait操作そのものが不要なキュー」(>>35)ではなく、 「wait操作を実装していないキュー」の意味に思えてきました。 こんな感じで合っていますか？ http://peace.5ch.net/test/read.cgi/tech/1253521167/43
45: デフォルトの名無しさん [sage] 2009/09/23(水) 11:23:13 >>43 > 欲しいのは、待機が可能なwait-free queueの実装クラスです。 「待機が可能な」ってことは BlockingQueue が欲しいってことだね。 BlockingQueueの実装方法は2つ。 ・待機しないQueueを用意し、要素が空だったらスピンしまくる。 ・「キューが空でない」という条件変数を用いたモニタ同期を組み込む。 前者は明らかにCPUの無駄遣い。 後者はlock-freeでもwait-freeでもない。 てことで、>>40にも書いたようにJavaのBlockingQueueの実装クラスが wait-freeでもlock-freeでもないのは、手抜きしているわけではなく そのように実装するのが不可能だからだ。 > wait-free queueの意味が「wait操作そのものが不要なキュー」(>>35)ではなく、 > 「wait操作を実装していないキュー」の意味に思えてきました。 だからそれは "wait-free" って言葉の意味を誤解してるって。 "wait-free" の wait とは、モニタ同期のwait()操作とかとは別物。 もちろん、sleep()とかyield()でもない。 http://peace.5ch.net/test/read.cgi/tech/1253521167/45
55: 35 [sage] 2009/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の実装技法が 確立し、標準ライブラリとして仕様化されることを願っています。 http://peace.5ch.net/test/read.cgi/tech/1253521167/55
80: 35 [sage] 2009/09/24(木) 11:59:49 (>>79の続き) このC++ by DDJ実装と、>>40が紹介してくれたJavaの実装とを比較すると、 lock-free/wait-freeの意味に違いがあるように感じられました。 C++ by DDJ実装のTIME_WAIT方式は、JavaであればBlockingQueueクラスに相当しますが、 >>40では、BlockingQueueクラスは(同期の実現はモニタ使用が前提だから) lock-free/wait-freeではない、と定義しています。 これらの一見矛盾しているように見える事柄を、自分なりに以下のように解釈してみました。 ・lock-free/wait-free単独では「同期を実現できない」 ・ただし、lock-free/wait-freeとスリープ(あるいはモニタ/conditionなど)とを組み合わせた制御を アプリケーション側で(たとえばクラスとして)実装することで「同期を実現できる」 誰も皆「排他」に関しては「実現できる」と見解は一致していますが、 この「同期」が「実現できる/できない」という解釈に関しては、人によって見解が 分かれているように思えます。違いは、「スリープ/モニタ/conditionなど」の使用を含めて 「できる」とする考え方と、それらは純粋なlock-free/wait-freeではない、とする考え方です。 難しい論争で、技術的な課題でもありませんから、私もこれ以上の考察は止めにします。 http://peace.5ch.net/test/read.cgi/tech/1253521167/80
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.024s