[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 17:44 / Filesize : 232 KB / Number-of Response : 919
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]
マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室 その6
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/

■過去スレ
その1 ttp://pc3.2ch.net/tech/kako/997/997345868.html
その2 ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その3 ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その4 ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その5 ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/

OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ

【OS】

【言語】

【実行環境】

【その他突起する事項】

656 名前:デフォルトの名無しさん mailto:sage [2009/08/04(火) 12:00:52 ]
無いんじゃない?atomicなカウンタでも使えばいいじゃん。

657 名前:デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:07:08 ]
>>656
もしそういうカウンタがもうあるなら再車輪せずに済むかな、と。

658 名前:デフォルトの名無しさん mailto:sage [2009/08/04(火) 18:51:12 ]
Linuxの話だけど、この件については他でも同じ
ttp://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
A thread does not maintain a list of created threads, nor does it know the thread that created it.

スレッド数だけであれば、psでスレッドの情報出すときと同じ方法でできる?

659 名前:デフォルトの名無しさん mailto:sage [2009/08/04(火) 21:20:30 ]
>>658
pstreeとかのソース読んだからまあ大体のことはできるんだけど
そうか、管理しないことをウリにしてんのか。仕方ないなぁ。
スレッド管理はOS任せか〜。そりゃそうだよなぁ。

660 名前:デフォルトの名無しさん mailto:sage [2009/08/09(日) 15:09:11 ]
Javaで複数のインスタンスのAというメソッドに同期をかけたい場合は、
どうすればよいのでしょうか?

661 名前:デフォルトの名無しさん mailto:sage [2009/08/09(日) 15:52:00 ]
>>660
同期は(メソッドにかけるものじゃなくて)メソッドが
アクセスするリソース(メモリやディスク)にかけるものだよ。
あと「同期」はスレッド間でイベントの発生待ち&発生通知を
実現する場合に使われる単語。もしもスレッド間で
(メソッドを通した)リソースへのアクセスの競合を避けるのが
目的なら、「排他制御(あるいはロック)」という単語を使うのが適切。

で、質問が(後者の)排他制御を実現する場合に関するもとすれば、
各インスタンスのメソッドAで(アクセスしたいリソースへの)
排他制御を実装するコードを単純に書けばいい、というのがレスになる。

もしも各インスタンスのクラスが同一ではないため、複数クラスで
メソッドのコードを変更するのはプログラム構造が複雑になると
考えているなら、たとえば以下のようなヒントが参考になるかもしれない。

・コールバック機構を利用して並行処理時に発生するバグを防止する
  japan.internet.com/developer/20050927/25.html

662 名前:デフォルトの名無しさん mailto:sage [2009/08/09(日) 16:02:51 ]
>>661
ご回答ありがとうございます。
プロセス起動時の初期処理用メソッド(DBからマスタを取得し、キャッシュする)に同期をかけたいと思っていました。
お返事どおり、メソッドではなく、リソース(オブジェクト)に対して、ロックをかけるのが正しいですね。
キャッシュクラスをシングルトンで実装し、同期化をさせることにします。

663 名前:デフォルトの名無しさん [2009/08/11(火) 00:33:30 ]
メソッドにsynchronizedを付けると、同一インスタンスで1つのスレッドしか実行できないということですか?
複数インスタンスあれば、実行できてしまうのでしょうか?

664 名前:デフォルトの名無しさん mailto:sage [2009/08/11(火) 00:50:50 ]
できてしまいます



665 名前:デフォルトの名無しさん mailto:sage [2009/08/12(水) 22:09:06 ]
staticメソッドなら大丈夫。
synchronized(Hoge.class) とか

666 名前:デフォルトの名無しさん mailto:sage [2009/08/12(水) 22:56:58 ]
>>665
> staticメソッドなら大丈夫。
> synchronized(Hoge.class) とか

そこまで書くならstaticメソッドじゃなくてもいいじゃん

667 名前:デフォルトの名無しさん [2009/08/16(日) 00:34:07 ]
マルチスレッド環境でマスタデータをDBからとってきて、HashMapかListなどに持たせるのは
問題ないのでしょうか?
基本的にJavaプロセスを起動している間にマスタデータが変更されることはない環境です。

668 名前:デフォルトの名無しさん [2009/08/16(日) 00:34:56 ]
667です。
データを持たせるHashMapかListはクラス変数で持たせたいのですが。

669 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 00:37:29 ]
情報不足
どういう問題がありえると思ってるんだ?

670 名前:デフォルトの名無しさん [2009/08/16(日) 01:02:48 ]
すみません。
HashMapとかListに数千件というマスタ情報を持たせるのがおかしくないのかという点と、
HashMapやListにデータを追加するときはロックをかけますが、データを取得するときは
ロックをかけなくても問題ないかを知りたいです。


671 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 01:16:29 ]
>>670
ハッシュなんてもんはメモリが許すなら数万件程度は入る事を前提で作るんだが


672 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 01:37:04 ]
>>670
(すでに別の方法で同期済み等で) 追加と取得が同時には起きないと判っているなら、取得同士の間のロックは不要
追加と取得が同時に起きるかもしれないなら、取得にもロックは必要

673 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 06:35:50 ]
通信とかどうでもいいから普通にマルチコアに特化したライブラリってないのさ?

674 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 08:59:53 ]
つintel TBB



675 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 09:49:44 ]
>>673
スレッド間通信が無くても役に立つマルチスレッドアプリとは何者?

676 名前:デフォルトの名無しさん mailto:sage [2009/08/16(日) 21:13:28 ]
ブルートフォースとか

677 名前:デフォルトの名無しさん mailto:sage [2009/08/17(月) 10:00:56 ]
>>675
サーバとか

678 名前:デフォルトの名無しさん mailto:sage [2009/08/18(火) 12:29:42 ]
pthreadでPSで表示したときのスレッド名を変える方法ってありますか?

679 名前:デフォルトの名無しさん mailto:sage [2009/08/20(木) 11:14:51 ]
ないんじゃない?

680 名前:デフォルトの名無しさん mailto:sage [2009/08/27(木) 19:59:12 ]
PR_SET_NAMEすればいいんじゃない?

681 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 15:32:43 ]
Cでマルチスレッドのプログラミングで
ふたつのスレッドの時間的な同期をとって
同時に同じファイルを開くにはどのように書けばよいですか

682 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 16:04:42 ]
>>681
そんなことできるんですか

683 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 16:11:59 ]
>>681
その発想はなかった

684 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 16:12:05 ]
>>680
ありがとう。とても役に立った。



685 名前:682 mailto:sage [2009/08/28(金) 16:18:17 ]
>>681
2つのスレッドから共通のモジュールを介してファイルにアクセスするようにしてはどうですか
2つのスレッドからは1つのファイルを開いているように見せつつ,
そのアクセス(読み書き)先の実体であるモジュールの中で排他制御するんです

686 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 17:14:56 ]
対象OSにどういった同期手段が用意されているかによる
どの程度同時性を求めるかにもよるし、それはつまり何のために同時でなきゃならないのかにもよる


687 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 20:01:11 ]
>>681
日本語の文章がちゃんと書けない人はプログラミングも出来ない。
by 竹内

688 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 20:10:31 ]
>>686
これ、日本語が致命的に下手なだけで、要点は
ただ排他制御したいってことだろ

689 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 20:20:01 ]
時間的な同期を取るってんだから、「同時」の意味が違うかもしれんぞ

690 名前:デフォルトの名無しさん mailto:sage [2009/08/28(金) 22:58:07 ]
日本語が下手ではなく、
頭の中で思考の同期が取れてないのでは。

691 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 02:53:56 ]
排他制御しないって意味かもしれんぞ

692 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 06:04:35 ]
まぁ、>>681がマルチスレッドでプログラミングすべきでないことだけは間違いないな…

693 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 08:12:32 ]
>>681
同時に開く保証はできない。
「ほぼ同じ頃に開くことができるかもしれない」が限度

694 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 08:32:21 ]
2スレッドをイベント待ちにしてから、同時に起こすのかと思った。



695 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 09:00:31 ]
マルチスレッドプログラムでのよくある落とし穴をまとめたサイトってどこかにない?

696 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 09:36:25 ]
>>695
ttp://www.itmedia.co.jp/enterprise/articles/0503/23/news086.html
まんまのがあるではないか。

>Windowsプログラマーでスレッドをいちども使ったことがない人はいないだろう。

一瞬それはないだろうと思ったがスレッド使わなきゃWindowsのプログラムは作れぬなw

697 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:12:44 ]
シングルはあるよな

698 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:14:07 ]
まぁ「プログラムなんてとりあえず動けばいいや」と考えている奴は大抵マルチスレッド関連でバグ出してハマるしな。

699 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 11:19:51 ]
>>698
そういうのは未だ救いようがあるが自分の痛さに気づいていない
プログラマーは救いようが無い。

700 名前:696 mailto:sage [2009/08/29(土) 11:39:02 ]
よく見たらゴミ記事であるな。
参考にしないほうが良い。スマヌ Orz

701 名前:696 mailto:sage [2009/08/29(土) 11:47:41 ]
ゴミ記事って言うのは酷すぎた。。
前提知識のない初心者が見ると混乱すると言うのが正しい。

702 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 18:11:28 ]
冒頭の四行くらいで日本語も問題切り分けも怪しく感じたから流し読みしたけど
どうでもよさそうな記事だった

703 名前:デフォルトの名無しさん mailto:sage [2009/08/29(土) 21:52:57 ]
シングルトン実装から始まって愚駄ぐだになって終わってると。

704 名前:名無しさん@そうだ選挙に行こう mailto:sage [2009/08/30(日) 10:25:00 ]
>>696の記事の二重チェックロックなんだけど

if (_Value == null) {
 lock (ValueLock) {
  if (_Value == null) {
   A temp = new A();
   Thread.MemoryBarrier();
   _Value = temp;
  }
 }
}
Return _Value;

これだと_Valueが更新される前にlockから抜ける可能性ない?
Thread.MemoryBarrier()するのは_Value = temp;の後じゃないの?



705 名前:名無しさん@そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:05:55 ]
_Valueの代入はlockの中にあるから、_Valueが更新される前にlockを抜けるわけはない
第2のスレッドがやってきて外側のif(_Value==null)を見たときに、
もし_Valueがまだnullならlockに引っかかるから最初のスレッドが更新を完全に終えるまで待たされるので問題ない (lock/unlock自体がメモリバリアになる)
問題は_Valueがすでにnullでなかった場合、_
Valueは新しいオブジェクトを指しているけれども_Valueの中のフィールドはまだ更新されてない、という事態が起きうる (メモリの書き込み順序は勝手に並び替えられるので)
それを防ぐためにメモリバリアを挟んで、_Valueが更新されるよりも前に_Valueの中身が更新されることを保証している

706 名前:名無しさん@そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:28:19 ]
_Valueが更新されるよりも前に_Valueが参照されないことを保証している

707 名前:名無しさん@そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:35:51 ]
_Valueへのアクセスは同期されてないから、lock中で_Valueが更新された直後から
他スレッドからAが使えるようになる。
でも

Aの構築
_Valueの更新
Aの構築の結果がAのフィールドに反映される

となる可能性があり、不完全な状態のAが使われる可能性がある。
だからAをnewした後にThread.MemoryBarrier()してから_Valueに代入する。
_Valueへの代入はlockを抜ける段階で保証される。

ということか。
勉強になった、ありがとう。

708 名前:名無しさん@そうだ選挙に行こう mailto:sage [2009/08/30(日) 13:39:37 ]
一応はっておく
www.ibm.com/developerworks/jp/java/library/j-dcl/

709 名前:デフォルトの名無しさん [2009/09/01(火) 20:32:30 ]
クアッドコアを使った並列処理を
MFCでのマルチスレッドでやろうとしておりますが、
シングルコアのときと同じマルチスレッドのプログラムでも
4つのコアを利用した並列処理になるんでしょうか?


710 名前:デフォルトの名無しさん mailto:sage [2009/09/01(火) 20:34:22 ]
なるよ

711 名前:デフォルトの名無しさん [2009/09/01(火) 20:38:55 ]
>>710
そうっすか!ならよかったです。

712 名前:デフォルトの名無しさん mailto:sage [2009/09/01(火) 21:08:29 ]
erlang

713 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 00:40:31 ]
>>709
MFCには詳しくないけどシングルコアで問題なく動いてたMTセーフのつもりの
プログラムがマルチコアにもってくと異常動作することはそれなりにあるん
じゃないの?int型への代入・参照を非同期でやってたりするプログラムだと。


714 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:07:14 ]
>>713
何故int? 64bit整数ならわからんでもないけど。



715 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:11:11 ]
つーかそんなことを質問してるわけじゃねーし。
言ってみたかっただけだろ。

716 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:05 ]
intでもread-modify-writeはatomicじゃないぞx86は(も)

717 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:18:42 ]
>>709
なる。OSネイティブのスレッドは、明示的に指定しない限り、複数のコアに分散される。
とは言え、排他制御が適切でないと、各コアを有効に利用できないけど。

718 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:27:46 ]
>>716
いや、それだったらそもそもデータ型問わんのでは。

719 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 01:33:30 ]
いやいや、おまいら、それ以前にそれはスレッドセーフと呼ばないのでは。


720 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 02:19:59 ]
>>718
64bitなら、と言ってるから、マシンワードならアトミックと思ってるのかなと思った

721 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 03:38:51 ]
volatile

722 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 06:06:12 ]
volatileがどうかしたか?

723 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 09:42:27 ]
vottakle

724 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:14:01 ]
明白な答えが、ここで出せるわけ無いんだから。
あなたが欲しいのは同意なんじゃないの?だから荒れる。



725 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:37:33 ]
>>724
独り言が言いたいだけだ、とかでないなら
最低限アンカーくらい書いたら?

726 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:55:09 ]
>>725
ごめんめっちゃ誤爆

727 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 13:57:38 ]
        ∧∧
       ヽ(・ω・)/   ズコー
      \(.\ ノ
    、ハ,,、  ̄
     ̄

728 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 14:27:31 ]
>>696
いまひとつ怪しい記事だな。
だいたい今の.NETじゃ前提が変わりすぎてて、役にたたないどころか害のが多い気がするし。


729 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:22:08 ]
>>720
64bitを持ち出したのは、32bitマシン(あるいは32bitモード)だと、単一の書き込み/読み出しでも競合すると値が壊れる可能性があるから。
(最初の32bitが書き込み前の、次の32bitが書き込み後の値を読み出す可能性がある)
マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?
あと、x86系だと、ワード境界をまたぐ読み書きがどうなるかがよくわからない。

730 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:40:02 ]
P6以降はキャッシュアラインドなマシンワードのreadやwriteはアトミックだよ
read-modify-writeはLOCK#がassertされないとアトミックじゃないよ
xchg命令は昔からLOCK#がassertされる仕様だからアトミックだよ

コンパイラも含めた挙動はこの辺も参考にするといいよ
msdn.microsoft.com/ja-jp/library/bb310595(VS.85).aspx

731 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 21:48:23 ]
ttp://www.intel.com/Assets/PDF/manual/253668.pdf
ここの 8.1 LOCKED ATOMIC OPERATIONS を嫁

732 名前:デフォルトの名無しさん mailto:sage [2009/09/02(水) 22:01:55 ]
>>729

>マシンワード以下なら、順序が入れ替わることはあっても値が壊れることはないと思ってるんだけど、それもあてにならない?

w

733 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 00:09:10 ]
The Art of Multiprocessor Programming
糞本だなぁ



734 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 03:59:45 ]
volatile



735 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 05:34:09 ]
volatile変数へのアクセスのアトミック性は、non-volatileな変数へのアクセスと同じ
だから、この流れにvolatileは何の関係も無いよ

736 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 09:27:34 ]
>>706
読み取り側ではメモリバリアはいらないの?


737 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 10:14:24 ]
_Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない・・・んじゃないかなたぶん

738 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:09:34 ]
>>737
>_Valueの値を読み込む前にその指す先の値を読み込むのは不可能だから
>メモリバリアがなくても読み込み順序は入れ替わらないはずで要らない
それが成り立たないアーキテクチャもあるんだな。
www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html

739 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:31:35 ]
volatileの話をするときは、C/C++なのかJava/C#(CLI)なのかをはっきりさせろ。
それぞれのvolatileの意味はまるっきり別なんだからな。

740 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 15:59:30 ]
そうか、やっぱりだめか
例の記事は今見直したらvolatileが付いてるな
なるほど

741 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:18:16 ]
それはメモりバリアかvolatileどっちかって話だから意味ないよ

742 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 16:36:48 ]
そろそろvolatileについて一言いっておくか
ttp://d.hatena.ne.jp/bsdhouse/20090720/1248085754

743 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:04:04 ]
C++っていつまでAtomicIntegerとかないわけ?
ふざけてないか?いい加減にしろ

744 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:06:40 ]
と言われても今年決まる新標準には採用されてるし
一企業や一個人に独占されてる言語と比べるなよ



745 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:10:45 ]
>>744
C++0xは2012年まで延期でしょ
今すごい揉めてるでしょ

746 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:13:31 ]
つーかC++使うならそのくらいはライブラリかAPIか自力で何とかできないと
結局他でつまづく

747 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 22:23:59 ]
ちょっと来週あたり
C++のatomic実装投下するから誰か100%
厳密に正しいか判断できる人いますか?

748 名前:デフォルトの名無しさん mailto:sage [2009/09/03(木) 23:38:00 ]
投下してから聞け。

749 名前:デフォルトの名無しさん mailto:sage [2009/09/04(金) 00:20:53 ]
現行C++ + Boost + TBBで組んでおけば、C++0xの時代になっても
スムーズに移行できるんじゃないかな

750 名前:デフォルトの名無しさん mailto:sage [2009/09/04(金) 22:04:46 ]
最近はC++の仕事が減ってC#とCばっかりになったお

751 名前:デフォルトの名無しさん mailto:sage [2009/09/04(金) 23:55:21 ]
blueroad.sakura.ne.jp/entry/20070815.php

752 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 00:54:22 ]
gccだとvolatileは付けても付けなくても
効果ないんだね

753 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:06:06 ]
SomeType() = default;

って奴を普通のC++に直すと
どうやってかけばいいの?

754 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 01:11:29 ]
>>753
// SomeType() = default;



755 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 04:53:21 ]
gccでもvolatile付けたら本来のvolatileの効果はあるだろ

756 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:45:20 ]
ちゃんと実装されているマルチスレッドアプリってあるのだろうか。
このスレ見てるとある特定の条件下でたまたま運良く動いているアプリばかりじゃないかと思ってしまう

757 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 09:50:07 ]
たまたまでもバグが入り込まなかったのならすばらしいことです


758 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:17:49 ]
このスレだけが世界のすべてだと想うなかれ

759 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 10:20:06 ]
引っ掛かりやすい問題点は多々あるが、ちゃんと分かってくれば安全に書ける
ただ、その「分かってくる」までのハードルがそれなりに高いから、手を出せる開発者
もなかなか増えないし、MTに対応することで恩恵の得られるアプリも少ないから、
MT対応アプリそのものがなかなか増えない訳だが
IntelもMTのフレームワークで金取ってる余裕ねーだろうにと思う(MSあたりは別に
どっちでもいいんだろうが)

760 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:09:19 ]
>>752

const volatile int x;

の説明も出来無さそうだな。


761 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:11:26 ]
ああ、const volatileの意味がすんなり理解できるかどうかはいいテストかもなw

762 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 11:50:26 ]
それがconst volatile autoな変数なら私には理解できません。

763 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:13:34 ]
C++0xのautoってcvとか*とか&とか付けられるんだろうか

764 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:27:55 ]
>>760
最適化されないRead Onlyな変数以外に何かの意味があるのか?



765 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:06 ]
別に最適化されない訳でもないが

766 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:29:18 ]
>>758
日本のマルチスレッドプログラム界の縮図がこのスレだと思っておりますが。

767 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:33:20 ]
ここには「実戦ではまだまだ書けませんが」って人もかなりいると思われ

768 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:39:42 ]
>>767
そういうヤツは時間の問題でちゃんと書けるようになる。
そんな自覚のないヤツほどマルチスレッドを使いたがる。

769 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 12:40:11 ]
「C/C++の」volatileを誤解してる奴はこれ↓読んどくといいぜ
ttp://mkosaki.blog46.fc2.com/blog-entry-91.html

770 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 13:58:48 ]
マルチスレッドってコンパイラの最適化やCPUの命令の実行順序まで
いちいち気にしていないとまともなプログラムは作れないって事ですか?

771 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:23:36 ]
いいえ
mutexやcondvarの使い方を知っていれば問題ありません

772 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:28:32 ]
mutexは遅いからイヤだ、などと言い出すから話がややこしくなるだけです

773 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:30:03 ]
condvar?

774 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:35:10 ]
条件変数
win32ならイベントオブジェクトか何か・・・・・・特定の出来事を待って寝ているスレッドを起こすメカニズム



775 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:17 ]
スレッド間通信そのものがボトルネックになるような場合は、mutexなんか使って
られないから>>770は真に近い
スレッド間通信のコストが無視できる場合は、>>770は偽に近い

776 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:42:37 ]
>>769
そのブログのおっさんって何者なんですか?

777 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 14:45:40 ]
スレッド管理APIを作る側なら>>770は真

778 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:07:19 ]
>>770
単純に動くものを作りたいなら、そこまでローレイヤーのことを考える必要はない。
が、
プログラムのパフォーマンスを上げたかったりするんだったら、
考える必要が絶対に出てくる。
「まともなプログラム」==「メジャーなソフトウェア」って認識なら、
言う通り、そこまで考えないとまともなプログラムは作れない


779 名前:デフォルトの名無しさん mailto:sage [2009/09/05(土) 16:08:26 ]
>>770
適当に作ってはったりかます方が金になるから
きちんとモノ作りする奴は馬鹿を見ると思った方がいいぞ

780 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 10:56:31 ]
mutexの速度が気になるようなプログラムなんて組んだことないぜ
速度より安定性重視な俺はプロだって周りかよく言われます

781 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 12:28:25 ]
必要無いならそれでいい
カーネルやドライバを書いてるような連中はそういう訳にはいかない
科学技術計算やゲームエンジンを書いてるような連中もな

782 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:20:16 ]
正しく動くものできっちり金を取った後、
また高速化するたびにきっちり金を取るのはプロだと思う。

783 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 13:31:25 ]
最初からある程度高速じゃないと金の取れない業種もあるけどな

784 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:14:35 ]
そういうプロが幅を利かせるから日本のIT業界はいつまでたっても土方っていわれるんだろな



785 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 14:18:37 ]
よく知らんけど海外でもそういう手合いはいるんじゃね?
変に胸張って「俺らこそがプロ」みたいな顔をしてるかは別として
Googleみたいなとこのプロはそういう手合いとは思えないしな

786 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 16:34:28 ]
>>780に同意する。

いかにmutexの回数やクリティカルセクションの範囲を減らすかに設計能力を注ぐ。
要は、スレッド間の同期を減らし、スレッドの並列度を上げることが目的。
ただし、(>>770の言う)コンパイラの最適化やCPUの実行順序までは考えない。
(>>782の言う)正しく動くものを作ることを最優先する。

マルチスレッディングと、その最適化には、高度に抽象化された思考能力と設計技術が要求される。
(>>778の言う)ローレイヤのことを気にした(言い換えると、ローレイヤの振舞いを前提にした)
スレッディングのロジックを組むということは、プラットフォーム依存な設計であるということ。
(>>781の例であれば)科学技術計算ならUNIXからWindowsへ、ゲームエンジンならPS3からXBoxへ
移植するたびにロジックの再設計が必要になる。

もしかすると自分が知らないだけで、(意図的に?)そういうローレイヤ前提な設計をして、
移植の度に利益を得るという(>>778,779,781のような)世界があるのかもしれない。
ただ、それは(>>784の言う)土方仕事と呼ばれる日本のIT業界の縮図そのものであると思う。

例外があるとすれば、カーネルの、しかもスレッドスケジューラやmutexそのものを実装する
コアなデベロッパに限る。彼らはハード(CPU)の能力を最大限に生かす基盤を作る人達だから。

787 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:00:35 ]
いや、普通に移植性の高いlock-free queueとか書けるから。

788 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:04:16 ]
ハードリアルタイムやったことないやつって性能無視の安定指向が強いよな


789 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:07:38 ]
マシンパワーの需要と供給の比がカツカツかトントンか余りまくりかで全然違うからな
それを無視して、どれか一つのパラダイムだけで語る奴は問題がある

790 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:08:37 ]
CompareAndSetとか、既に
どの開発環境でもインラインアセンブラ関数
用意されてるから、CPU変わっても大した話
じゃないよ



791 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:24:48 ]
ところでお前らlock-free queue
とか朝飯前なんだよな?

なぁどうなんだ?

792 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 17:28:54 ]
>>789
ですよねー周りの見えない技術者ほど使えない物はないです


793 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 19:15:48 ]
物理シミュだと、精度が要るところは安定性重視でそうでないところはピーク性能重視。
マシンパワーの配分はジョブによって違うから動的に。

794 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:30:11 ]
>>791
Javaのマルチスレッド本にlock-free queueの実装が載ってたんだが。
「どうやってlock-freeを実現しているのか」は何とか理解できたが、
自分で一から書けるか、と聞かれると胸を張って「No!」と答えるしかない。



795 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 21:32:03 ]
>>791
俺は今書いてる
書いたらここにうpして

虐めて貰おう

796 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:00:21 ]
要求条件によって実装も細かく変わるからなぁ、lock-freeは

797 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:08:59 ]
IntelのMathKernelLibraryはやばい
あれこそプロの仕業だ

798 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 22:28:11 ]
>>781のような世界では
LockFree程度じゃ満足されないぞ。

RCUとかを使ってCasFreeにして、
メモリバリア(バスロック)を減らさないと充分ではないと言われるんだ。
メモリバリアがあると、シングルコアでもバスクロックで数クロックを消費するが
これが他のコアのCASが原因でも起こるわけだからな。

799 名前:デフォルトの名無しさん mailto:sage [2009/09/06(日) 23:31:17 ]
>>797
MKLは、OpenMP対応しているから勿論OpenMPで並列実行させてもいいのだけれど。
意外なことに、MKLを使ったプロセスを複数同時実行させてもリニアリティが高いのが凄い。

800 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:19:14 ]
>>798
lock-freeが要求によって実装がまちまち、ってのはそういうのも含めたつもり
CASは使わないがメモリモデルや要件的にRCUも不要な場合とか、色々あるからなぁ

801 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:20:34 ]
ロック中に、割込処理みたいなコンテキストスイッチしない人が飛び込んできたら
デッドロックしちゃうけど、一般的にこういうのはどうやって回避する?

802 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:31:35 ]
飛び込ませないとか

803 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 01:35:48 ]
割り込み処理の中で何かをロックするというのはやめようよ

804 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 07:16:58 ]
>>801
longjump



805 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 09:58:24 ]
ロックって他のスレッドをロックしなければコスト低いのな
特定のクラスの関連のない処理を同じロックオブジェクト使ってすげー遅かったのが
処理ごとに別のロックオブジェクト使うようにしたら殆どコストが無くなった

当たり前だよな・・・


806 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 11:44:54 ]
>>805
では聞くが、それは本当にロックする必要があったのか?w

807 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 11:54:40 ]
あるし

808 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 12:56:39 ]
ロックの粒度は可能な限り小さくする派です
でもそれ以前になるべくロックしないでいいように設計します


809 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 15:37:35 ]
それが言いたかったんです
けど小さいロックを連続でするくらいなら少し大きなロックを1回の方が効率いい時もある

810 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 15:47:31 ]
以前ねえ、ロックの粒度を細かくしていったら
滅多に競合しないのに、オブジェクト毎に計数千個のロックが作られる事態になったことがある。
(rwlockのエミュレーションで、Win32でやってみたらHANDLEの使用量が跳ね上がったり)

で、こういう場合はどうするのが妥当?

1) そのまま数千個使う
2) ハッシュ等でロックを減らす
3) がんばってrease-releaseする形にする

まあ3)が一番まともかと思うんだけど
CASとかを使ってうまく解決できるのかな。

811 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 15:55:47 ]
>>809
> 少し大きなロックを1回の方が効率いい時もある

ロジック的に必須な少し大きなロックを洗い出して、ち
まちま小さなロックを作らないように設計するかな。

大抵他のものと絡めて排他する必要が多いから、部品単
位にロックを用意することはあまり無い。

「粒度を小さくする」っていうのはその上でロック期間
が短くなるようにすることだと思ってる。

812 名前:デフォルトの名無しさん mailto:sage [2009/09/07(月) 22:00:28 ]
compare_exchange_strong
compare_exchange_weak

の違いってなんなんですか?



813 名前:801 mailto:sage [2009/09/08(火) 01:50:20 ]
割り込み中に重たい処理をやりたくないから、割り込みじゃない人に
重い処理をやらせようと思って、タスクキューみたいなのをこしらえて
せっかくだから処理を全部タスクキューにやらせようと思ったのよ
そしたらキューにタスクを積む処理で詰んだ

814 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 02:16:44 ]
頑張って、「キューに追加/取り出しの処理」をlock-freeにするんだ。
場合によってはキューのデータ構造から書き直して、な。



815 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 07:56:26 ]
単純にタスクキュー触る間だけ割り込み禁止に・・・

処理させたいタスクに対応するビットフラグ立てるだけでもよくない?

816 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 09:53:40 ]
割り込みで lock-free キューに詰んで、表側で適当な
ディスパッチタイミングで必要な処理を起こす、ってい
うのなら出来そう。キューの保持数が 0 → 1 のタイミ
ングで通知を送って…とかだと詰みそう。

817 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 10:22:40 ]
lock-free のほうが簡単では?
たとえば、A B Cの処理は衝突無し、順序関係無しだったら
3つのスレッドのキューに渡すだけでしょ?
なんで、マルチスレッドは、排他制御や、待ちの方が発展したのか不明。こっちの方が難しいだろ。

818 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 10:37:33 ]
lock-freeって、実際にどういうアトミック命令を組み合わせて実装すんだ
それっぽい紹介サイトがみつからねぇ・・・

819 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 10:57:57 ]
アトミック命令はアルゴリズム次第で不要だろ。
このようにしたら、メモリの共有部分は出ないから、失敗は出ない。
すべてこのような分割にしたらいい。

> 預金残高の書き換え処理をn並列で行いたいなら、n個Wait-freeキューを作り、
> 口座番号をnで割った余りでどのキューに入れるか決めるという方法で対応できる。

Lock-freeとWait-freeアルゴリズム - Wikipedia
ja.wikipedia.org/wiki/Lock-free%E3%81%A8Wait-free%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0



820 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 11:08:36 ]
コンペア・アンド・スワップを使わないと
処理がうまくいかないケースを知りたい。


821 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 11:16:06 ]
なにこれむずい

822 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 11:48:12 ]
>>815
割禁は嫌だしビットは複数積めないよね

823 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 14:47:46 ]
>>820
俺は逆にCAS無しで上手くいくケースを教えて欲しい

824 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 15:57:19 ]
>>822
以下の方法なら、これなら(フラグの)ビットは1個あれば済むよ。
実際にUNIXのデバイスドライバ(STREAMS)で実装した。

タスクキューを複数のサービススレッドが共有する。
割り込み処理ではタスクキューにイベントを入れてフラグを立てる。
複数のサービススレッドが一斉に起きて、最初にスケジュールされた
スレッドだけがイベント取り出しに成功しフラグを落とす。
他のスレッドはタスクキュー空(から)なので、再び待ち状態に入る。
割禁の範囲はタスクキューとフラグを触る時だけ。

UNIXでハードなリアルタイム性は要求されないから、可能な手法だけどね。



825 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 16:08:34 ]
Mac OS X 10.6(Snow Leopard)の話題だけど、
こんなのはWindowsやUNIX/Linuxでは常識なのかな?

マルチコア時代の新機軸! Snow LeopardのGCD(Grand Central Dispatch)
ascii.jp/elem/000/000/455/455786/

826 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 16:12:39 ]
ぜんぜん常識じゃないよ。
Mac OS はいい意味で、ようやっとるなと思う。

827 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 17:14:56 ]
まだ途中までしか読んでないが

完全自動じゃないけど
IOCPでの、CPU数にあわせた同時実行数自動決定が、似たような仕組みなんじゃないか。
プールするスレッド数は(一般にCPU*2とか言われているが)自由なんだし。

ただ、ライブラリやフレームワークがそれを利用するように作られているか、といえば
答えは明らかにノーだけどね。

当然、言語仕様なんか触ってないから、
一つ一つのジョブは自分で切り分ける必要があるし、
手間は段違いだろうね。

828 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 17:36:21 ]
>>826
しかし、依存性のないブロックに分割するのは手作業なので、
その記事で絶賛されているほど楽になった感じはしないけどな。
結局自分でワーカースレッドを起こさなくてもいいってだけなので
windowsでいうと、ファイバを利用したスケジューリング用のライブラリがあって
それを利用してコードを書いてるような感じだ。


829 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 17:51:51 ]
斜め読みだけどOpenMPの発展系といった感じかな?
MSだとParallel LINQに近い気がする。

830 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 17:58:20 ]
>>823
819の預金処理は、同時にメモリにアクセスすることは無いだろうが。
口座番号 % n ごとに処理する。 それぞれのスレッドは独立していて
各スレッドが順次処理している限り、衝突など無い。

831 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 18:17:30 ]
>>828
依存性を判断してブロックに分割すれば、あとはフレームワークまかせなのだから、
設計者にとっては、かなり負担を減らせるのでは。Apple絶賛はさておき。

判断そのものの自動化は、副作用が前提な手続き型言語では非常に困難だから、
データフロー型言語が一般化する時代にならなければ実現しないと思われ。
今の流行ならHaskellやF#みたいな関数型言語が近い位置にいる。

あと、GUIライブラリとの連動が考慮されている点も設計者にとっては大きいね。
画像編集や3DCGみたいな分野で、Macの勢力が一気に増大する要因になるかも。

832 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 18:42:19 ]
>>824
割禁が使えないときはどうするよ

833 名前:824 mailto:sage [2009/09/08(火) 19:15:59 ]
>>832
(>>824の話は)割禁が使えるUNIXデバドラでの実装だから、
割禁が使えないときのことは分からない。

というか、割禁がまったく使用禁止な世界(ドライバ開発?)というのが想像つかないんだけど。
サービススレッドは定期的に(Lock-Freeな)キューをのぞきにいくのかな。
それほどレスポンス性能にシビアな世界で、ポーリング方式を採用するのは逆効果な気がする。

Lock-free/Wait-freeには全く詳しくないんだが、割禁が使えない世界というのを、
もしよければ教えてくれないか?

834 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:03:26 ]
>>819
>> 預金残高の書き換え処理をn並列で行いたいなら、n個Wait-freeキューを作り、

「Wait-freeキューを作り」の中で、アトミック命令が使われているんだが
そういう意味では無いのかな。
単に「自前で実装する必要があるか否か」という意味なら
いくらでも「○○は不要」なものがあるだろう。

>>833
「割り込み処理」というのはハード的にはまあ確かに割り込みだが
処理内容的には、「別スレッドからの非同期な処理要求を処理するか」に近い。
つまり、割り込み禁止とは「排他ロックを獲得してから処理を開始する」
ということと同様になる。
実際、あまりに長時間割り込みを禁止していると割り込み要求が破棄されるものがあったと思うが
これは、別スレッドからのtrylock要求が規定に達したのであきらめる、というのと同じかと思う。

だから何ってほどでもないけどね。
実際には、「割り込み処理の入り口でロックを獲得」という
(やってはいけない)やり方をせずに済むわけだから。
ただし、通常は競合が無い限りCAS2回で済むロックの獲得/解放の変わりに
システムコールにつながるであろう割り込み禁止処理を入れるというのは
普通のユーザーアプリケーションにとっては
コストが大きすぎて採用できないだろうけどね。
(x86のcli/stiも特権命令だしね)



835 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:12:24 ]
>>834
Wait-free関連のどんなライブラリも不要だろ。
このケースだとスレッドをn個つくって、
各スレッドは、渡された処理を順にこなすだけ。
どこにも衝突するところは無い。
( 同銀行間での送金処理があればぶつかるが。)

836 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:20:46 ]
要するに、メモリ共有のある部分を並列処理しなければ、何の問題も出ないって事だな。
メモリ共有しながら並列処理しなければ、出来ない(パフォーマンスが落ちる)
ケースってどんなのがあるの?
アルゴリズムの工夫で解消無理なの?

837 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:20:56 ]
>>835
そのスレッドに処理を渡す時点で、CASが必要だと思うが。

838 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:24:45 ]
>>837
そうか。
処理を渡す側が、マルチスレッドの場合があるか。 ATMは日本全国にあるからね。

839 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:26:17 ]
そりゃ、同期の必要が無い処理なら、CASもロックも不要。
当たり前すぎて笑えてくる。

840 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:39:27 ]
口座番号でスレッドに分けて、ATM毎に格納するメモリを確保しておいて
メモリの先頭から、順に処理すれば衝突は出ない。
後ろの番地のATMは番が回ってきにくいけど。
そこでさらにATM番号でスレッド分けて、一スレッドで処理するATM数を1000個とかにすればいいだろう。

841 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:41:15 ]
お前はスレッド(口座)に対するディスパッチに、同期処理が必要無いとでも思っているのか。
さては、ATMでの出金だけで、振込みとかやったことないだろ。

842 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:43:29 ]
で、まあ、実際のところ、処理によってはCASが不要なものも確かにあるよ。
少し前に書いたけど、RCUとか使ってね。
(>>819の書き込みがあまりにもアホっぽいから突っ込まれてるだけでね)

ただ、RCUはそれはそれで破棄のタイミングが問題になるし
破棄するものをキューに入れるとかする場合にはそっちでCASが必要になったりとか
適用できる範囲が限定されるんだけどね。

843 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:46:51 ]
口座間の送金処理ありの場合に、同期処理を不要にするアルゴリズムが存在するか考えてみる。

844 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 20:49:53 ]
>>841
むしろ、同じ口座に対する複数の処理があるからこそ、同期が必要と言える。
各口座がスレッドを持っていて、それぞれがwait-freeなキューを持っていたとしても
それに対しての追加/取り出しにはCASが不可欠。
少なくともwait-freeである限り。と
ja.wikipedia.org/wiki/Lock-free%E3%81%A8Wait-free%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0#.E3.82.B3.E3.83.B3.E3.83.9A.E3.82.A2.E3.83.BB.E3.82.A2.E3.83.B3.E3.83.89.E3.83.BB.E3.82.B9.E3.83.AF.E3.83.83.E3.83.97
には書いてある。



845 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 21:02:45 ]
とりあえず、RCU的な使い方
いわゆる「volatileで充分」な処理は
「更新の競合が絶対に起こらない」というのが大前提だから。

更新が競合する可能性がある場合は、必ずCASが必要になるはず。

846 名前:843 mailto:sage [2009/09/08(火) 21:11:45 ]
2つ以上の口座から、一度に入金が来る場合が問題か。
841の様に、入金用に、口座毎にメモリを確保しておき、先頭から処理すれば衝突避けられる。
しかし、口座数×口座数だけのメモリが必要になり実用的でなさそう。


847 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 21:13:41 ]
トランザクショナルメモリないと
こんなのCASだけあっても意味ねージャン


848 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 23:07:25 ]
ドライバ開発で、割り込みハンドラでさわるリソースが、
通常コンテキストで触るリソースと競合するなら、
割り込み禁止以外ないと思ってたけど、そうでない
一般的なやり方があるなら教えてほしいのぉ。

マルチコアだと、単一CPUの割り込み禁止だけでは
不十分でspin_lockとかいったりするが。

849 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 23:21:44 ]
>>848
割込ハンドラは割込スレッドを起床させるだけ。
割込スレッドと通常コンテキストとの間の排他は優先度継承付きmutexで行なう。

てな感じで

850 名前:824 mailto:sage [2009/09/08(火) 23:27:18 ]
>>834
レスありがとうございます。
非同期な処理要求がガンガン発生するケースについては分かりました。

ただ、もし処理要求がまったく発生していないアイドル状態の時、
サービススレッドは処理要求の発生をどのように待っているのでしょうか?
たとえば、以下のようなループを組むとか考えたのですが、

while (queue.empty) yield(); /* yield()は他のスレッドへ制御を移す関数 */

システムはアイドル状態にもかかわらず、スレッドがCPUを浪費してしまいます。
Wait-freeライブラリ(?)の中で、新たな処理要求が発生するまで
サービススレッドをwaitさせてくれるような仕掛けが実装されているのでしょうか?

851 名前:824 mailto:sage [2009/09/08(火) 23:31:28 ]
>>849
え、ハード割り込みの延長でmutexを呼ぶのですか?
もし競合していたら割り込みがwaitする(?!)ことになるので、
一般的なドライバ開発ではあり得ないと思うのですが。

852 名前:デフォルトの名無しさん mailto:sage [2009/09/08(火) 23:44:55 ]
>>851
だから「優先度継承付き」と言っているではないか。
Solaris Internalとかを読むべし。

853 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 00:14:40 ]
>>852
優先度継承したら、割り込みコンテキストぬけて通常コンテキストに
スイッチするん?Solarisは。んなことはないと思うが。

割り込みスレッドを起床するだけというのは普通だと思うが、
割り込みスレッドを起床している間は、通常大本のハードの
割り込みは禁止するよね。禁止するときにレジスタアクセスとか
あってwaitいったりすると、やっぱり通常コンテキストと
割り込みコンテキストで排他は必要になると思うのだが。

854 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 01:00:18 ]
>>853
> 優先度継承したら、割り込みコンテキストぬけて通常コンテキストに
> スイッチするん?Solarisは。んなことはないと思うが。

割込スレッドがmutexでブロックしたら、mutexの競合相手(これは通常コンテキストかもしれない)にコンテキストスイッチして、
mutexの排他区間を抜けさせる。
そしたら元の割込スレッドの処理を続行することができるよね。



855 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 01:06:23 ]
>>853
ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8A%E8%BE%BC%E3%81%BF%E3%83%8F%E3%83%B3%E3%83%89%E3%83%A9
> 割り込みスレッド
> Solaris、Mac OS X、FreeBSD などのOSでは、割り込みスレッド(Interrupt thread)と
> 呼ばれる方式が採用されている。割り込みハンドラは高優先度のスレッドであり、割り
> 込みによって起動され、排他制御でブロックされるという重要な特徴がある。


856 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 01:46:16 ]
>>854>>855
だから、割り込みスレッドと、割り込みコンテキストはちゃうっつーのに。
2chで何かを期待した俺がアフォだったよ。

857 名前:824 mailto:sage [2009/09/09(水) 01:56:56 ]
>>852
Solarisは専門外なので書籍は持っておらず、Sunのサイトで
Writing Device Drivers という文書を斜め読みしてみました。
以下は第8章 Interrupt Handlers の節 Interrupt Handler Overview
からの引用です。
docs.sun.com/app/docs/doc/816-4854/interrupt-15678?l=ja&a=view

.... The job of the interrupt handler is to service the device and stop the device from interrupting. When the interrupt handler returns, the CPU resumes the work it was doing before the interrupt occurred.

ここには「割込ハンドラがデバイスからの割込を禁止し(stop)、ハンドラがリターンすると
CPUは以前の処理を再開(resume)する」とあります。これは割禁を指していると思うのですが....?

Solarisの場合には、デバイス構造体に「特殊な」優先度付きmutexが含まれているみたいですね。
割込ハンドラが、この特殊なmutexを操作することで割禁制御を実現しているように推測できます。
ただし、この優先度はハード割込の優先度であって、スレッド実行の優先度ではありません。
また、このmutexの操作対象はデバイス(の割込)であって、割込ハンドラとサービススレッドとの
間にあるリソースでもありません。

スレッド間の排他制御に用いられる「一般的な」優先度継承付きmutexと混同していませんか?


858 名前:824 mailto:sage [2009/09/09(水) 02:22:51 ]
>>854
たとえコンテクストスイッチしたとしても、その間に再度ハード割り込みが
次々に入ったらどうなりますか?それを避けるのが割禁の役目だと思います。

>>855
「割り込みスレッド」というブラックボックスな言葉を鵜呑みにしていませんか?
そのwikipediaからの引用部分の前段には、割り込みハンドラが第1レベルと
第2レベルの2つの部分に別れているとあります。Solarisの場合であれば、
カーネル(デバイス)内にあるのが第1レベルであり、その「実行中は割禁」される。
また、デベロッパが作る割り込みハンドラが第2レベルであり、
一般的には「割り込みスレッド」と呼ばれている、と自分は解釈しています。

結局、割り込みスレッド方式であっても「デバイスドライバにおいては、
割禁は避けられない」と思うのですが、間違っていますか?
Solarisの場合には、特殊なデバイスmutexによって割禁制御を抽象化しているから、
デベロッパは割禁を意識せずにデバドラを開発できる、という説明なら理解できますが。

859 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 03:16:16 ]
うーん、なんか論点がずれてきているような…
> ドライバ開発で、割り込みハンドラでさわるリソースが、
> 通常コンテキストで触るリソースと競合するなら、
> 割り込み禁止以外ないと思ってたけど、そうでない
> 一般的なやり方があるなら教えてほしいのぉ。
ってのに対して「少なくともSolarisは違うよ」と言いたいだけなんだけど…

>>857
> たとえコンテクストスイッチしたとしても、その間に再度ハード割り込みが
> 次々に入ったらどうなりますか?それを避けるのが割禁の役目だと思います。

たとえば、ディスクIOに関する割り込み処理を行なっているときに
クロック割り込みが発生したら、クロックの処理を優先させるべきだからそっちの割り込み処理を先におこなう。
でも、クロック割り込みを処理しているときにディスク割り込みが発生しても、ディスク割り込みの処理は後回しにされる。
そういう制御を行なうために「割り込みレベル」ってのはある。
# これは「割り込みスレッドの優先度」とは違うもの。
でも、これはリソースの排他のためのものじゃないよね。

> そのwikipediaからの引用部分の前段には、割り込みハンドラが第1レベルと
> 第2レベルの2つの部分に別れているとあります。Solarisの場合であれば、
> カーネル(デバイス)内にあるのが第1レベルであり、その「実行中は割禁」される。
> また、デベロッパが作る割り込みハンドラが第2レベルであり、
> 一般的には「割り込みスレッド」と呼ばれている、と自分は解釈しています。

第2レベルもカーネル内にあるものだよ。
というか、Solarisでは第1レベルと第2レベルが明確に分かれておらず、
割り込みハンドラは、最初のうちは割り込んだスレッドのコンテキストを「借りて」処理をおこなう。
で、mutexでブロックすることになった時点で、完全なカーネルスレッドとして設定され、コンテキストスイッチが起こるの。
ただ、このとき優先度逆転現象が起こって競合したmutexがいつまで経っても開放されなかったらマズいので、優先度継承の仕組みが働くってこと。

860 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 03:47:59 ]
調停スレッドを置く形態だとCASは別に必須じゃない。普通にwikipediaの記事が間違ってる。

861 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 04:17:44 ]
なんだいきなり

862 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 10:18:21 ]
>>825
スレッドプールとの何がちがうのかわからない・・・教えてエロイ人!

863 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 10:30:12 ]
記事を斜め読みしただけだけど、
ブロックの中から外側のローカル変数を見れるようになってるっぽいのは便利そう
どういう扱いなのかしらんけど

864 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 11:03:00 ]
>>862
スレッドプール+タスクキューってのは定番の仕組み(たとえばJavaのThreadPoolExecutorとか)だけど、
それを利用しやすくするためにClosureを言語拡張として用意したのは凄い。



865 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 11:07:29 ]
昔俺が作ったモニタだとハードウェア割り込みが入った
ら別の割り込みで失われる情報(割り込み要因とか)だ
け保存してまず enable interrupt してたな。

>>859 のいうようなレベル設定はハードウェアで実施さ
れてた。だから自動的に高いレベルのものが順次受け付
け可能だったよ。

>>857 は「じゃあ同じ要因の割り込みが割り込み処理中
に発生したら?」と思うかも知れないが、それはそもそも
処理が間に合ってないってことだ。

866 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 11:09:11 ]
> ブロックの中から外側のローカル変数を見れるようになってるっぽいのは便利そう

ていうかクロージャーってのは基本的にそういうもん。

867 名前:801 mailto:sage [2009/09/09(水) 15:00:41 ]
すまないですがデバイスドライバとかそういうのに限定した話ではないので
割り禁に相当するものはないという前提でおねがいします。

関係ないけど割り金って書くと玉がキュッとなるよね

868 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 17:55:18 ]
>>862
スレッドプールを使いこなせている人にはあんまり関係ない気もするが、
初めてマルチスレッドに触れる人にとっては敷居が低いと思うの

869 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 17:57:37 ]
>>867
>関係ないけど割り金って書くと玉がキュッとなるよね
女の子だからわからないわ

870 名前:デフォルトの名無しさん mailto:sage [2009/09/09(水) 20:24:24 ]
> 昔俺が作ったモニタだとハードウェア割り込みが入った
> ら別の割り込みで失われる情報(割り込み要因とか)だ
> け保存してまず enable interrupt してたな。

ふつーのOSは、割り込みを発生させた割り込みだけ禁止して
他の割り込みを許可して割り込みハンドラをよびだすよね。
だから当然他の割り込みは受付可能。ハンドラ呼び出す前に
発生させた割り込みまで許可するような変態^H^H面倒くさい
実装はゆるさん。

> >>857 は「じゃあ同じ要因の割り込みが割り込み処理中
> に発生したら?」と思うかも知れないが、それはそもそも
> 処理が間に合ってないってことだ。

間に合ってないっつーか、割り込みコンテキストで割り込みを
発生させた要因をクリアもしくは禁止しないで、割り込み
コンテキスト抜けたら無限に割り込み入り続けるっつーことを
言ってるだけなんじゃね(レベル割り込みなら)

871 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 00:10:55 ]
言語本ではなくマルチスレッドプログラミングの基本を概念からわかりやすくまとめた本があれば売れると思う

872 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 00:11:47 ]
>>871
自作OS入門読めば解るだろ



873 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 16:04:04 ]
>>871
Win32マルチスレッドプログラミングがオススメ
コードはwindowsのapi使ってるけどスレッドの概念とか使い方とかわかりやすく書いてる
まぁ絶版になってるみたいだけどね

874 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 16:41:09 ]
>>871
「Java並行処理プログラミング」がオススメ。
絶讃している人も多い。
d.hatena.ne.jp/higepon/20090326/1238067284
入手が非常に困難だけど、復刊交渉も始まったらしいので、
興味があったら投票よろしく。
www.fukkan.com/fk/VoteDetail?no=46255
blog.book-ing.co.jp/fukkanrepo/2009/09/post-76fd.html



875 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 17:04:39 ]
>>870
> ハンドラ呼び出す前に 発生させた割り込みまで許可
> するような変態^H^H面倒くさい実装

これ、割り込みコントローラがカスケード接続されてる
場合は要るかも。

玄関から割り込みを受け付けて「本当は誰だったか」を
調べて、そのハンドラを呼び出す前に他のハンドラの為
にもういっぺん玄関を開けたりとか。

結局「本当の誰か」に EOI 発行するまでその人からの
再度の割り込みは来ないからマクロに見れば同じだけど、
ハンドラ実行から後を別スレッドでやるように考えれば
割とスマートなんじゃないだろうか。

876 名前:デフォルトの名無しさん mailto:sage [2009/09/10(木) 23:01:47 ]
>>874
Java向けの本ではあるけど、確かにお薦めだと思う。


877 名前:デフォルトの名無しさん mailto:sage [2009/09/11(金) 18:27:02 ]
>>871
言語に依存しない入門書は確かに欲しい
各言語での扱いは巻末にちょろっと載ってるぐらいでイナフ

878 名前:824 mailto:sage [2009/09/11(金) 22:29:34 ]
>>859
遅レスになりましたが、頭を冷やして考えまてみました。

>でも、これはリソースの排他のためのものじゃないよね。

古典的なOSでは、割り込みコンテクストとサービススレッドとの間にある
リソースの排他のために、割り込み禁止、あるいは割り込みレベルを(一時的に)上げることで
実現していたけど、「少なくともSolarisは違うよ」ということですね....

>第2レベルもカーネル内にあるものだよ。

より正確には、カーネル空間内にある、ですよね。

>割り込みハンドラは、最初のうちは割り込んだスレッドのコンテキストを「借りて」処理をおこなう。
>で、mutexでブロックすることになった時点で、完全なカーネルスレッドとして設定され、
>コンテキストスイッチが起こるの。

つまり、通常は(競合が発生しない場合は)、割り込みコンテクストとしてハンドラは動き、
その間は割り込みレベルを上げる事で、(同じレベルでの)新たなハード割り込みの発生を防ぐ。
ただし、競合が発生すると(mutexでブロックされると)、割り込みコンテクストは終了して(リターンして)、
カーネルスレッドへのコンテクストスイッチが発生し、残りの処理を継続するという訳ですね。

これなら割り込みコンテクスト内での処理オーバヘッドを最小限に押さえつつ、
同時に、ハンドラとサービススレッド間のリソース排他を実現できるような気がします。
STRAMSのput&srvエントリと同じ考え方ですね。

詳しい解説、ありがとうございました。よい勉強をさせてもらうことができました。
自分としては納得できたので、このデバイスドライバ実装に関する話題は、これで終わりにします。

879 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 15:29:31 ]
アトミック変数クラス(C++0xのstd::atomic<T>みたいなやつ)の
ソースとか作り方ってどこかにあります?

880 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 15:31:50 ]
>>879
あるけど教えない

881 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 15:48:03 ]
>>879
もしWindows使いなら、Win32APIのInterlockedIncrementなど、Interlockedから始まるAPIの使い方を調べればよい。


882 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 15:56:27 ]
「ソースとか作り方」って見た時、
一瞬、lock + cmpxchg とか lock + xadd のことかと思ってしまった。
そんなわけないよな。クラスって書いてるし。

883 名前:879 mailto:sage [2009/09/12(土) 20:37:05 ]
>>881 >>882
大体予想はつくし実の所もう作ってはあるんだけど、
キャッシュの整合性とか色々考え出すと生半可な知識ではどうしようもないので、
既存の検証された実装があればいいなと思って。

884 名前:デフォルトの名無しさん mailto:sage [2009/09/12(土) 20:55:54 ]
ttp://www.dre.vanderbilt.edu/Doxygen/5.6.6/html/ace/a00029.html



885 名前:デフォルトの名無しさん [2009/09/13(日) 02:31:59 ]
Art Of MultiProcessor本の10章
ABA問題Pragma10.6.1のところで
CompareAndSet(T expectedReference, T newReference, int expectedStamp, int newStamp)
ってなメソッドが定義されてる。

これってDCASっぽいのだが
質問は説明の後半
「C/C++でやるなら64bitアーキテクチャなら"stealing"bits from pointer,
32bitアーキテクチャでも間接参照?でできる(although a 32-bit architecture woild probably require a level of indirection.)」
ってあるがどうやるんだ?

わかる人、教えて。



886 名前:デフォルトの名無しさん [2009/09/13(日) 02:51:31 ]
上の質問の追記

ReferenceとStampがどっちも小さい値なら
例えばintegerの上と下で16bitづつつかって
maskで値を取り出すとか工夫できるだろうけど、

例えば32bitマシンで
referenceもstampもどっちも32bitの値を使う場合にどうするんだろう
ってのが質問。



887 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 09:02:36 ]
そりゃペアで保持するオブジェクトの領域作って
そこへの参照をCompareAndSetするんじゃないの?


888 名前:デフォルトの名無しさん [2009/09/13(日) 11:05:39 ]
>>887
cmpxchg使ったことある?


質問変えると
x86、Cでcmpxchgでどう書くか


889 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 11:18:48 ]
俺も普通に>>887としか思えないし>>885の英文もそう読めるしCASも理解してるが

890 名前:デフォルトの名無しさん [2009/09/13(日) 11:34:02 ]
俺わかんねorz
具体的にCとgasで疑似サンプルコード書いてもらえると助かる


891 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 11:58:41 ]
>>890
金かかるよ?
高いよ?

いいの?

892 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 12:01:27 ]
いいよ。>>890にツケとけ。

893 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 12:36:05 ]
みんな
ほんとにできんの?

64ビットと32ビットのアーキテクチャのアプローチの違いもいわず
ただ「オブジェクトつくって...」って
分かった気しただけで実装したことないんちゃうか
cmpxchg使うんだよ



894 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 12:46:12 ]
>>893
cmpxchg直接使うってバカか勉強中の学生以外
使わないと思うけど?

キミいくつなの?レベル低すぎなんだよね〜



895 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 14:31:59 ]
x86前提ならそもそも64ビットCAS命令がネイティブでなかったっけ?


896 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 17:11:34 ]
>>x86前提ならそもそも64ビットCAS命令がネイティブでなかったっけ?

元の質問読んだ?
DCASっぽい動きをCAS命令でやるのってどうやるのって話。


誰も64ビット版ではstealing bits、
32ビット版ではindirectionの意味も語らず、
厨房よばわりしてるけど
誰も原著を読み込んでないし実装もできないじゃないか

>>cmpxchg直接使うってバカか勉強中の学生以外
>>使わないと思うけど?
>>キミいくつなの?レベル低すぎなんだよね〜

ようするに出来ないんだろ


897 名前:デフォルトの名無しさん [2009/09/13(日) 17:19:40 ]
>>894

このメソッド、
x86の32ビットと64ビットの両アーキテクチャ上で
Cで実装してみ?
cmpxchg使わないでw



public boolean compareAndSet(V expectedReference,
V newReference,
boolean expectedMark,
boolean newMark)

「現在の参照 == 予想される参照」であり、現在のマークが予想されるマークに等しい場合、参照およびマークの値を指定された更新値に原子的に設定します。

パラメータ:
expectedReference - 参照の予想される値
newReference - 参照の新しい値
expectedMark - マークの予想される値
newMark - マークの新しい値
戻り値:
成功した場合は true



898 名前:デフォルトの名無しさん [2009/09/13(日) 17:20:42 ]
IntelのTBBってどうですか
使える? これから主流になる?

899 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 17:28:52 ]
一部はC++0xに取り込まれるので、やっておいて損はないと思う。

900 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 17:35:48 ]
>>898
TBB使ったアルゴリズムが100%正しいのか
検証する手段がないから危険で使えないよ?



901 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 17:42:44 ]
原子的に、って訳は正直どうかと思う

902 名前:デフォルトの名無しさん [2009/09/13(日) 18:51:04 ]
>>896

つttp://www.nagi.org/diary/?date=20090614#p01


903 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 18:55:38 ]
原子的に

quark的に

904 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 19:40:00 ]
不可分的に



905 名前:デフォルトの名無しさん [2009/09/13(日) 21:07:54 ]
結局、ここの連中は自分じゃコードが書けない
知ったかばっかりなんだな

906 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 21:14:41 ]
>>905
まず金を払え
話はそれからだ

907 名前:デフォルトの名無しさん [2009/09/13(日) 21:31:47 ]
>>906

馬鹿らしいが相手にしてやると
サンプルコードも書けない奴に先払いするやつなんていない。

slealing bitsってどういう意味だ?
せめてこれの意味くらいきっちり説明してみろ。

全然わかってねえじゃねえか、このスレの連中w


908 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 21:58:35 ]
>>907
キミってその解ってないと卑下する連中と同列なんじゃないの?
ちなみに、煽れば回答でてくると思ってるでしょ?



909 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 22:15:16 ]
>>907

キミってこんなのも書けないの?
template<typename T>
bool compareAndSet(T* const expPtr, T* const newPtr, const uint32_t expStamp, const uint32_t newStamp)
{
bool r = false;
if(v == expPtr && s == expStamp) {
TAS.lock();
if(v == expPtr && s == expStamp) {
v = newPtr;
s = newStamp;
r = true;
}
TAS.unlock();
}
return r;
}


TASぐらい実装できるよね?そこまでバカじゃないよね?
Javaの実装とVCかgccのcompareAndSwapのインラインアセンブラ
組み合わせれば実装ぐらいできるでしょ?それもできないってレベル低すぎるでしょ?

キミだめだわ



910 名前:デフォルトの名無しさん [2009/09/13(日) 22:47:13 ]
えーとだな、
そもそもの質問はArtOfMultiProcessor本の
Lock-Free Queueの実装なんで

おお威張りでlock()使われると
失笑するしかないんだがなw

君は本当の馬鹿なんだね


911 名前:デフォルトの名無しさん [2009/09/13(日) 22:51:26 ]
>>ちなみに、煽れば回答でてくると思ってるでしょ?

902に回答出てるじゃん。

できる人は出し惜しみしないで公開してるし回答もできるだろう。

ここに張りついてる連中は揚げ足とりばっかで
質問の本質も理解できない知ったかばっか


912 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 22:53:20 ]
>>887で終わってんのに何で続いてんの?

>誰も64ビット版ではstealing bits、
>32ビット版ではindirectionの意味も語らず、
当たり前すぎて説明する必要があるとも思わんわ。

64ビットではポインタのビットから一部拝借してスタンプに使う。
32ビットではポインタとスタンプをまとめて直接ではなく、
ペアの領域を作成してそのポインタで間接的にCASを行う。


913 名前:デフォルトの名無しさん mailto:sage [2009/09/13(日) 23:08:05 ]
>>912
uint64_t expV = ((((uint64_t)expPtr) << 32) | ((uint64_t)expStamp));

uint64_t newV = ((((uint64_t)newPtr) << 32) | ((uint64_t)newStamp));

return (expV == CAS64(&ptr, expV, newV));

これでOK?

914 名前:デフォルトの名無しさん [2009/09/14(月) 00:17:59 ]
>> 887で終わってんのに何で続いてんの?

909みたいなのが質問者を馬鹿にしたんで荒れたんじゃないの。
lock使ってCASを実装するような奴が威張り散らしてるのみて爆笑させてもらったよ。
いずれにしても知ったかが多いのが明らかになったのはよかったんじゃない。


>>912

当り前すぎたとしても、質問者みたいな初心者もいるから最初から説明してあげれば。




915 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 00:39:43 ]
どう見ても、キミが質問者で
煽って回答を引き出してるだけに見えるけど。

週末だしね。

916 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 00:56:51 ]
>>913
uint64_t expV = ((((uint64_t)&expPtr) << 32) | ((uint64_t)expStamp));

uint64_t newV = ((((uint64_t)&newPtr) << 32) | ((uint64_t)newStamp));


917 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 01:00:27 ]
>>894
>>908
>>909
>>915

煽ってる同一人物なんで
無視の方向で


918 名前:デフォルトの名無しさん mailto:sage [2009/09/14(月) 04:16:34 ]
火元の人
 やり方が理解できない質問者
 俺に分からないならこのスレにも理解できる奴いないんじゃね、とか思っていて、
 それが態度にも滲み出ている

煽る人
 分かってるつもりだけど分かってないで煽り続ける
 こいつを見た火元は「やっぱり分かってる奴いないんじゃないか」と思いこむ

住人タイプA
 一目で分かるがお前の態度が気に入らないしコード示すのマンドクセ
 つーかこの説明で分かれボユゲ

住人タイプB
 みんな何言ってんだかわかんね






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<232KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef