1001コメント311KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2006/09/10(日) 00:13:53

マルチスレッドプログラミングについて語るスレ。
OS・言語・環境は問わないが、それゆえ明記すべし。

その１ http://pc3.2ch.net/tech/kako/997/997345868.html
その２ http://pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ http://pc8.2ch.net/test/read.cgi/tech/1098268137/
その４ http://pc8.2ch.net/test/read.cgi/tech/1130984585/

0002デフォルトの名無しさん

2006/09/10(日) 00:19:06

関連スレ

【マルチコア】並列化について語る【使いこなせ】
http://pc8.2ch.net/test/read.cgi/tech/1137540671/

pthread地獄 (UNIX板)
http://pc8.2ch.net/test/read.cgi/unix/1010933537/

関連しやすいので一応

ネットワークプログラミング相談室 Port17
http://pc8.2ch.net/test/read.cgi/tech/1148944560/l50

書籍とかはもういいでしょ

0003デフォルトの名無しさん

2006/09/10(日) 00:33:25

乙

0004デフォルトの名無しさん

2006/09/10(日) 15:04:22

4ね

0005デフォルトの名無しさん

2006/09/10(日) 16:03:40

5免蒙る

0006デフォルトの名無しさん

2006/09/11(月) 07:05:53

pthreadで排他制御やりたいときはmutexしか選択肢は無いんでしょうか？

0007デフォルトの名無しさん

2006/09/11(月) 22:08:46

condition,semaphore

0008デフォルトの名無しさん

2006/09/18(月) 01:43:12

本とかはもういいとして、このソースのthread部分は秀逸だっていうの
教えてください

0009デフォルトの名無しさん

2006/09/18(月) 09:25:39

apache2(ウソ)

0010デフォルトの名無しさん

2006/09/18(月) 10:05:22

Windowsのスレッドのタイムスライスは、上限が20msと聞きますが
これを制限する方法はありませんか？
できれば、3～5msに押さえたいのです。

0011デフォルトの名無しさん

2006/09/18(月) 16:44:32

NT4.0を使って、boot.iniで設定。
Windows Embeddedならどっかで設定できたような。
Vistaは割り込み頻度を変えるAPIがあったかもしれず。

0012デフォルトの名無しさん

2006/09/18(月) 20:34:42

Ｆｉｂｅｒ使ってで明示的にスイッチするとか

0013デフォルトの名無しさん

2006/09/18(月) 21:47:30

>>11
ありがとうございます。
こちらでも調べてみたのですが
win9x/2000でのスレッド単位での設定は出来ないようですね。
スレッドスケジューラを少しいじれば、可変に出来る気がするのですが
あんまり需要無いんですかね。

>>12
ファイバを使ってsuspendを置くか、スレッド関数にSleepを置くか、
結局のところ、これしかしかないのですね……
どちらか採用して、今のプロジェクトを進めようと思います。

0014デフォルトの名無しさん

2006/09/19(火) 10:53:29

>>10

たしか、どっかにVistaのタイムスライスに関する blogがあったな。
××をすると、スイッチが最小時間になると適らないとか。

どっかの、MVPの blogだったと思う。

0015デフォルトの名無しさん

2006/09/19(火) 21:01:54

>>14
Vista+タイムスライスでググってみた。
ttp://d.hatena.ne.jp/NyaRuRu/searchdiary?word=*%5BVista%5D
ついでに
ttp://www.itmedia.co.jp/help/tips/windows/w0129.html

0016デフォルトの名無しさん

2006/09/21(木) 21:28:56

InsideWindowsには
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl]
のWin32PrioritySeparation
をいじればいいと書いてある

0017デフォルトの名無しさん

2006/09/21(木) 22:55:26

ってスレッド単位で制御したいのか

そりゃ無理っぽいな

0018デフォルトの名無しさん

2006/10/07(土) 12:26:02

ほ

0019デフォルトの名無しさん

2006/10/10(火) 14:57:19

>>14
kernel修正すればいいじゃん。
2.6.xなら安定してるしNPTLを使えばOKだし

0020デフォルトの名無しさん

2006/10/10(火) 21:20:44

0021デフォルトの名無しさん

2006/10/26(木) 16:02:30

マルチプロセスのプログラムはWindowsで作れますか？

0022デフォルトの名無しさん

2006/10/26(木) 17:21:43

>>21が意図してるものとは異なるかもしれんが、マルチプロセスのアプリケーションなら作れる。
しかし>>21の質問の仕方からして、>>21には到底無理だろう。

0023デフォルトの名無しさん

2006/11/04(土) 17:13:38

質問させてください。
Win32APIのSuspendThread()に自スレッドを指定して、
自分自身を眠らせるということは可能でしょうか？

0024デフォルトの名無しさん

2006/11/04(土) 18:06:36

試せばいいじゃん

0025デフォルトの名無しさん

2006/11/04(土) 18:47:40

どうやって起こすの？
イベントオブジェクト作ってWaitForしたほうがマシだと思うが・・・

0026デフォルトの名無しさん

2006/11/04(土) 19:11:44

>>24
すいません、「可能」は「アリ」に置き換えてくださいorz
一応動くんですが、何かマズイんじゃないかなぁと思いまして。

>>25
仰るとおり実用的ではないですが、ちょっと気になったもので…

0027デフォルトの名無しさん

2006/11/06(月) 15:24:05

>>23
他スレッドからResumeThreadしようとしたとき、Resumeしても SuspendThread の直前だったため
Resume後即 Suspend してしまうケースがある。 → 解決するためには「スレッドのステート(idle,busyなど)」を設けて、
排他的に操作する必要あり。適切なイベントオブジェクトを使って待つ方が良い。

それでもまぁ他のスレッドを Suspend するのに比べればはるかに罪は少ない。

0028デフォルトの名無しさん

2006/11/07(火) 09:09:31

408 ：名無しさん＠お腹いっぱい。：2006/11/05(日) 18:14:14
Kentsfield(1P4C) vs Woodcrest(2P4C)
http://www.hardwarezone.com/articles/view.php?id=2102&cid=2&pg=4
Opteronサーバー死んだな…
Clovertown 1.60GHz $455*2 >>> Opteron 2220 SE $786*2
Clovertown 2.33GHz $851*2 >>> Opteron 8220 SE $2149*4

0029デフォルトの名無しさん

2006/11/09(木) 22:08:24

967 名前：923[sage] 投稿日：2006/09/09(土) 17:29:41
>>959
＞intrinsicはスルーか。
済みません、仰りたいことの意味が良く分りませんでした。
このプログラムの要点は、

volatile long a = 0x00001111;
void thread1(){
　while(1)a=0x00001111;
}
void thread2(){
　while(1)a=0x22220000;
}
int main(){
_beginthread(thread1);
_beginthread(thread2);
　while(1)if(a != 0x00001111 && a != 0x22220000)エラー;

return 0;
}

です。組み込み命令云々の余地があるのでしょうか？

main, thread1, thread2が開始される。
～～～時間が十分経過～～～
thread2が動き出す。a=0x22220000が実行される。
mainが動き出す。a!=0x00001111の評価をする。真であった。
thread1が動き出す。a=0x00001111が実行される。
mainが動き出す。a!=22220000の評価をする。真であった。
mainが動き出す。エラー処理を行う・・・？？？。

0030デフォルトの名無しさん

2006/11/10(金) 02:13:19

複数のスレッドを起動する場合、
システムに異常が発生しても全てのスレッドを
必ずきちんと終了させたい場合、各スレッドで try catch
入れるんでしょうか？
それとも別に良い常套手段があるんでしょうか？

0031デフォルトの名無しさん

2006/11/10(金) 06:01:09

システムに異常が発生した事を検知する関数が真を返したらすべてのスレッドが自主的に終了するようにしたらいいんちゃうん？

0032デフォルトの名無しさん

2006/11/10(金) 08:53:37

ええんちゃう？最高ちゃう？

0033デフォルトの名無しさん

2006/11/10(金) 09:56:27

volatile最強伝説復活ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

0034デフォルトの名無しさん

2006/11/10(金) 19:04:31

このスレも自主的に終了するようにしたらいいんちゃうん？

0035デフォルトの名無しさん

2006/11/10(金) 20:51:25

ええんちゃう？最高ちゃう？

0036デフォルトの名無しさん

2006/11/10(金) 23:12:02

>>29

while(1)if(a != 0x00001111 && a != 0x22220000)エラー;
を分解して
while ( true )
{
if ( a != 0x00001111 ) // a is 0x22220000
{
if ( a != 0x22220000 ) // a is 0x00001111
{
throw std::runtime_error("死んでしまえ");
}
}
}

0037デフォルトの名無しさん

2006/11/17(金) 16:54:00

>>36
こうすりゃいいんじゃね？

while(1){
int _a = a;
if(_a != 0x00001111 && _a != 0x22220000)エラー;
}

要は00001111か22220000以外が見つかればエラーにしたいんだから。
>>29指摘のコンテキストスイッチによる嘘エラー検出は回避できる。

0038デフォルトの名無しさん

2006/11/19(日) 14:18:42

初心者です。
スレッドの状態（実行中・サスペンド中など）を知るＡＰＩってありますか？

State = ResumeThread( th_handle ) 又は
State = SuspendThread( th_handle )
として　サスペンドカウントを見て状態を更新させています。
状態を監視する別スレッドがこのStateを見て、レジューム・サスペンドの実行をおこなっているのですが、

どーやら、状態を監視するスレッドが見ているStateと実際の状態が異なるらしく、
レジューム中のスレッドにResumeThread　を実行したり、サスペンド中のスレッドにSuspendThread　を実行しちゃったりしています。

なにかアドバイスもらえませんか？
おねがいします。

OS : Window XP Home
言語: C++
環境: VC++6.0

0039デフォルトの名無しさん

2006/11/19(日) 14:24:04

resume/suspendよりも、event objectやwindow messageを使って
眠らせることをオススメするよ。

004038

2006/11/19(日) 14:35:34

>>39

アドバイス、ありがとうございます。
イベント使って、再設計してみます。

それと、色々さがしたんすけど、やっぱりスレッド状態を知るＡＰＩとかは
ないんすかね？

0041デフォルトの名無しさん

2006/11/19(日) 14:39:09

知ったところでどうしょうもない、とだけ言っておこう。
だからないのよ。

004238

2006/11/19(日) 14:45:36

>>41
了解です。ありがとうございます。

助かります～

0043デフォルトの名無しさん

2006/11/19(日) 17:51:29

>>40
状態を調べたところでその次のステップで状態が変わってる可能性もあるわけで、
結局、排他やロックなどが必要になるわけです。
だったらはじめから>>39の方法の方が妥当なのです。

004438

2006/11/19(日) 23:36:56

38です。
イベント使って再設計したとこ、なんとか思い通りに動いてくれました。
みなさん、どうもありがとう。
いい勉強になりました～

0045デフォルトの名無しさん

2006/11/20(月) 16:10:26

linux上のＣ言語での質問です。

pthread_create を使ってスレッドを生成すると、そのスレッドが完了しても
１個スレッドが残るんですが、これって開放出来ないんですか？

デバッガで調べると「pthread_managear」というスレッドのようなのですが。

0046デフォルトの名無しさん

2006/11/20(月) 20:40:45

>>45
スレッドマネージャもためらいきずばかりなんだよね
自殺はよくない

0047デフォルトの名無しさん

2006/11/21(火) 01:19:01

どのlinux？
それなくなったとか聞いたんだが

0048デフォルトの名無しさん

2006/11/21(火) 09:28:07

>47
ＲｅｄＨａｔＬｉｎｕｘ７．３です。

0049デフォルトの名無しさん

2006/11/21(火) 19:20:58

pthread_joinしてないとかそういう話じゃないの？

0050デフォルトの名無しさん

2006/11/22(水) 13:33:05

>49
joinはしてます。
あと、pthread_detach も試して見ましたが変わらずでした。

0051デフォルトの名無しさん

2006/11/23(木) 14:14:40

windows c言語です。
_beginthreadexでスレッドを数千つくろうとしてるのですが、
スレッド数４００ぐらいこえたところで、_beginthreadが０を返しだすので仕方なくsleepいりのbusyloop
で待って_beginthreadしつづけています。
スレッド数をタスクマネージャでながめると４００になり、だんだんへって１０桁程度になってから
また４００に跳ね上がるのくりかえしをして、正常に終了します。が遅いです。
だんだん減っているときにはすぐに次の_beginthreadが成功してくれて、
なぜ、４００のままずっといき、最後がだんだん減っておわらないのかわからないです。
あと、なぜ４００で限界になるのでしょうか？
ちなみにスタックサイズをでかくするとスレッド数の限界はもっと減ります。
メモリがどんどんくわれていってスレッドももっとたくさんできて欲しいのですが・・・
スレッドの内容はメモリを動的確保しhtmlをネットから拾ってきて読むものです。

これだけでわかる人　ヒントください。

0052デフォルトの名無しさん

2006/11/23(木) 14:19:52

>>51
http://www.biccamera.com/bicbic/jsp/w/pcoption/memory/0407/index.jsp

0053デフォルトの名無しさん

2006/11/23(木) 15:12:17

>>52
え　それはないと思う。
プロセスの使用メモリ３５MBぐらいなんです。
全部で１Gつんでるのに。

0054デフォルトの名無しさん

2006/11/23(木) 15:25:10

スタックメモリサイズの制限でしょ

0055デフォルトの名無しさん

2006/11/23(木) 16:03:20

> スレッドの内容はメモリを動的確保しhtmlをネットから拾ってきて読むものです。

ジョブキューイングとかワーカスレッドとか知らんかね？

0056デフォルトの名無しさん

2006/11/23(木) 17:00:57

１プロセスにスレッド４００個ってのは設計上どうなんだろ…。
タスクマネージャ見ても最高でSystemの７８個程度だ。

0057デフォルトの名無しさん

2006/11/23(木) 21:32:18

>>56
同意。

スレッドの生成と、管理にはそれなりのコストがかかるから、
むやみに増やしてもかえって遅くなる。

せいぜい数個から１０数個くらいにとどめておくべきと思う。

0058デフォルトの名無しさん

2006/11/23(木) 22:29:39

数千スレッド使いたいってあほか。

0059デフォルトの名無しさん

2006/11/23(木) 23:13:58

PCの玄海に挑戦したかっただけだろうよきっと

0060デフォルトの名無しさん

2006/11/24(金) 01:00:08

どうもスレッドからみでは、本当に同時平行に処理したいことと、
そうでないことの区別ができてないことが多いようだ。

0061デフォルトの名無しさん

2006/11/24(金) 01:07:32

この場合は
・ネットへのリクエスト
・得られた情報の分析
が並行処理対象になると思うんだが、
前者と後者ではやりかたがぜんぜん違うよなあ

0062デフォルトの名無しさん

2006/11/24(金) 01:45:14

あまりのスケールのでかさに、別件でスレッドを使おうか迷っているのが
バカらしくなってきた

0063デフォルトの名無しさん

2006/11/24(金) 02:08:29

うちだと_beginthread()しまくるだけの奴で
スレッド2000個ちょっとまで作れるな

0064デフォルトの名無しさん

2006/11/24(金) 14:14:52

ふと>51の質問みて思ったんですが、スレッドを分ける（並列にする）
と処理速度って上がるんでしょうか。

処理の内容によるでしょうけど、単純にＣＰＵ性能に依存するような
処理で、並列に処理可能な場合とか。

まあ普通そういう目的でマルチスレッドを利用したりするわけじゃないですが。

0065デフォルトの名無しさん

2006/11/24(金) 14:15:53

ふと>51の質問みて思ったんですが、スレッドを分ける（並列にする）
と処理速度って上がるんでしょうか。

処理の内容によるでしょうけど、単純にＣＰＵ性能に依存するような
処理で、直列に処理してたけど並列に処理可能な場合とか。

まあ普通そういう目的でマルチスレッドを利用したりするわけじゃないですが。

0066デフォルトの名無しさん

2006/11/24(金) 14:16:56

連書きスマソ；

0067デフォルトの名無しさん

2006/11/24(金) 15:08:49

>>64
動作中スレッド数よりもCPUコア数が多いなら、スレッドを並列化することで高速化する。
仮に1Core1CPUで単純に並列化した場合、全く高速化しないかオーバーヘッドの分遅くなる。
まぁ、CPUコア数の数倍以上のスレッドを起こすと資源の競合が発生するから速くなる筈がない罠。

0068デフォルトの名無しさん

2006/11/24(金) 16:02:59

>>67
CPUに限らず、資源が競合する処理なら、確かにそうなるな。

逆に言えば資源を競合しないI/Oウェイトなどが多い処理なら、
ＣＰＵ数より極端に多いスレッド数でも処理は早くなるといえる。

たとえば今回のようなhtmlファイルのダウンロードの場合、
相手方のサーバーのレスポンス待ちが発生するので、複数のスレッドで別々の
htmlファイルを同時に取得しにいったほうがいい。

ただ、やりすぎると今度はスレッド切り替えとか、メモリスワップとか、回線速度の限界とかで
オーバーヘッドが大きくなるので遅くなる。

0069デフォルトの名無しさん

2006/11/24(金) 16:05:55

tcpip.sysの同時接続制限とか関係ないのかな?

0070デフォルトの名無しさん

2006/11/24(金) 18:03:54

>67 68
サンクス！
実はウチの作ってるアプリで性能を指摘されてるトコがあって、
並列化ってどうなんだろうと思ったんで、参考になりました。

とりあえずＣＰＵ依存の処理は効果薄って事ですね。

0071デフォルトの名無しさん

2006/11/24(金) 19:12:42

>>70
並列化を考える前に、やることは色々あると思うよ。
CPUに、P4以上の制限つけていいならiccでコンパイルしてみるとか。
iccがあれば、並列化も簡単に試せるしね。
まぁ、詳細はスレ違いになるんで省略するけど。

0072デフォルトの名無しさん

2006/11/25(土) 01:58:51

CPU依存の処理で高速化を考えるなら、並列化ではなくアルゴリズムの最適化を考えたほうがいい。

スパコンでもない限り、今のパソコンはせいぜい４コア。
並列処理させても、４倍未満にしかならない。

だけどうまくアルゴリズムを工夫すれば、数倍から数百倍の速度が稼げる可能性がある。

0073デフォルトの名無しさん

2006/11/25(土) 02:07:56

DELLの６万円パソコン買ったほうがよくね？
１０台でも６０万。さてアナタの２人月より安い？高い？

0074デフォルトの名無しさん

2006/11/25(土) 02:08:38

無限に並列化可能な処理と仮定するなら、クラスタリングもありかと。
所謂グリッドコンピューティング。

0075デフォルトの名無しさん

2006/11/25(土) 02:12:36

あと２倍になればいいだけなのにチューニングだとかほざいて
無駄にコードを複雑にしようとしていたボケがいたので
サーバを３倍に増やして終わりにしました。

0076デフォルトの名無しさん

2006/11/25(土) 02:53:01

ま、そこら辺は完全にケースバイケースだよね。お仕事でやってるならコスト次第。
このスレ的には並列度を上げる方向に収束すると美しいんだけど。

0077デフォルトの名無しさん

2006/11/25(土) 03:05:17

そんな勝手に方向を決められても。

0078デフォルトの名無しさん

2006/11/25(土) 12:57:34

>>71
＞iccがあれば、並列化も簡単に試せるしね。
体感で速くなったためしがない。

いったいどういう場合に効果があるのか…。

人間が見ればすぐ分かるが、コンパイラの並列可能判定って
どの程度のものなんだろう。

0079デフォルトの名無しさん

2006/11/25(土) 12:58:54

↑もちろん手動で並列化したら高速化できる状況での話ね。

0080デフォルトの名無しさん

2006/11/25(土) 13:11:18

>>78
勿論、最低限-parallelは指定しているとして、単純なループなら並列化してくれる可能性はあるよ。
尤も、OpenMPを手軽に試せるという積もりで書いたんだけど。

0081デフォルトの名無しさん

2006/11/30(木) 20:10:54

Sunコンパイラ最強伝説

0082デフォルトの名無しさん

2006/12/02(土) 20:35:28

最近、コンパイラの最適化性能比較ってあんま情報ないな。

0083デフォルトの名無しさん

2006/12/03(日) 21:51:02

すいません、マルチスレッドですか？

0084デフォルトの名無しさん

2006/12/03(日) 22:42:46

はい、マルチスレッドです。

0085デフォルトの名無しさん

2006/12/03(日) 23:28:53

あなたを、マルチスレッドです。

0086デフォルトの名無しさん

2006/12/06(水) 23:09:42

今日は徹夜でpthreadを勉強します。

0087デフォルトの名無しさん

2006/12/07(木) 01:09:39

こんやは徹夜で、マルチスレッドです。

0088デフォルトの名無しさん

2006/12/07(木) 11:08:50

それはいいマルチスレッドですね。

0089デフォルトの名無しさん

2006/12/07(木) 22:25:54

俺はみんながマルチスレッドしたあとでいいよ

0090デフォルトの名無しさん

2006/12/07(木) 22:29:26

みんないっしょでこそマルチスレッドです

0091デフォルトの名無しさん

2006/12/07(木) 23:01:07

俺ちょっと疲れたからみんな先にいってくれ

0092デフォルトの名無しさん

2006/12/08(金) 03:40:09

急激にスレの質が落ちて参りました

0093デフォルトの名無しさん

2006/12/08(金) 14:50:27

みんなでマルチコスレッドしねぇ？

0094デフォルトの名無しさん

2006/12/08(金) 21:05:24

JavaScriptの分際でマルチスレッドしてやがる事に最近気付いた。
仕組みどうなってんのよ？

0095デフォルトの名無しさん

2006/12/08(金) 21:57:49

Javascriptなら中身見れるでしょーが

0096デフォルトの名無しさん

2006/12/08(金) 22:03:46

ソースの問題じゃなくてCPUがどう処理をこなしているか知りたいんだよな

0097デフォルトの名無しさん

2006/12/09(土) 00:36:36

並行動作はせんと思うが

0098デフォルトの名無しさん

2006/12/09(土) 00:59:15

CPU？

0099デフォルトの名無しさん

2006/12/09(土) 01:01:50

onBlurとonClickで並列処理するよ。

0100デフォルトの名無しさん

2006/12/09(土) 01:02:26

だめだこりゃ

0101デフォルトの名無しさん

2006/12/09(土) 01:14:01

0102デフォルトの名無しさん

2006/12/09(土) 01:18:19

？

0103デフォルトの名無しさん

2006/12/09(土) 01:28:07

どのブラウザで？
つかブラウザネタをここでやるのか・・・ヤだなあ

0104デフォルトの名無しさん

2006/12/09(土) 04:50:27

ここはやっぱり伝家の宝刀 volatileネタを持ち出して本来のスレの荒れ方に戻そうよ。

0105デフォルトの名無しさん

2006/12/11(月) 10:38:50

Intel C++ Compiler for LinuxでOpenMPを使った並列化をやっているのですが、Intel Thread ProfilerにはLinux版が存在しないので、
暗黙的/明示的なバリア, ループの分割, critical構文等のオーバーヘッドや負荷の不均衡が検出出来ず、いまいちパフォーマンスが伸び悩んでおります。
このような問題を解決できるLinux用のツールは存在するのでしょうか？
それともWindowsに移行するという選択肢しかないのでしょうか？
なんだかレベルの低い質問で慙愧に堪えないのですが、もし誘導や解答をいただければ嬉しいです。

Intel Thread Profiler
http://www.intel.com/cd/software/products/ijkk/jpn/threading/310854.htm

0106デフォルトの名無しさん

2006/12/11(月) 18:47:00

一昔前だったらまともなスレッドプログラミングしたけりゃSolaris使え、で
片付けられてたような気がするけど私も興味あるので識者の降臨を待つ。
Valgrind(Helgrinid)の他にLinuxで実用に耐えるツールはあるのかな、と。

0107デフォルトの名無しさん

2006/12/11(月) 19:06:34

とりあえず脳味噌ぶら～んから適当に検索。
ttp://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%B3%AB%C8%AF%B4%C4%B6%AD%B7%CF#Debugger
ttp://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%B3%AB%C8%AF%CA%E4%BD%F5%A5%C4%A1%BC%A5%EB%B7%CF#Profiler

0108105

2006/12/11(月) 22:40:37

>>106-107
御解答有難う御座います。
わざわざ検索していただいたのに申し訳ないのですが、ちょっとその中には無いようですorz
凹んでいるだけでは何にもならないので、とりあえず"OpenMP"でググって片っ端から有望そうな所を覗いてみました。
結果、Omni OpenMP Compilerにtlogviewなるツールがあることがわかりました。
http://phase.hpcc.jp/Omni/openmp-tutorial/sld049.htm
これを使えば、「iccでOpenMPを使った限界までのパフォーマンスチューニング」は難しそうですが、
「自分のコードの駄目なところ(計算粒度、ロードバランス等)を効率的に見つける」ことはできそうな感じです。
これを使って駄目だったらWinへの移行も検討してみようと思います。

0109デフォルトの名無しさん

2006/12/11(月) 22:42:55

SolarisがN:Mスレッドモデルをやめたのは効率が悪かったから？

0110デフォルトの名無しさん

2006/12/11(月) 23:45:55

アプリが1:1モデルを前提に作られる（チューンされる）ようになったから。
アプリといってもぶっちゃけoracleだが。
SolarisのためだけにN:M用チューンするのは時間の無駄だからね。

これを効率というならば効率だね。

0111デフォルトの名無しさん

2006/12/20(水) 09:58:49

I/.O主体の仕事は前提とかチューンってこととは関係なく、
1:1の方が効率がいい場合が多いでしょ。
CPUを明け渡すのがカーネル内であることが多いから。
だからエンタープライズが主戦場のSolarisでは当然のことかと。

0112デフォルトの名無しさん

2006/12/20(水) 10:23:41

OSが1:1ばかりになったというのもあるよ

0113デフォルトの名無しさん

2006/12/21(木) 01:18:13

そういうことは関係ない。
ちゃんと選んでやっている。

0114デフォルトの名無しさん

2006/12/21(木) 01:28:43

M:Nはシグナルの動きが1:1のときと全く同じにはならない。
両モードでのデバッグや検証コストを掛けられない。

もう一つは>>112のとおり。
OS屋のオナニーで仕様が決まる時代は終わった。

0115デフォルトの名無しさん

2006/12/22(金) 22:55:26

マルチスレッドのデバッグではまっています
（私が作ったんじゃないのですが）
beginthreadが50個、EnterCriticaSectionが40個くらい、
スレッド最大200個くらいが動くとんでもないシステムです。
（もちろん満足に動いてないです）

とりあえず、下記の方針でソースをチェックしようと思いますが、
他にもありますでしょうか?

１　InitializeCriticalSection()以前の行に、_beginthreadを呼び出す関数に入ってないか
２　スタティック変数、グローバル変数にEnterCriticalSecitonなしで書き込みを
行ってないか
３　newで作ったオブジェクトのポインタを複数のスレッドで参照してないか

0116デフォルトの名無しさん

2006/12/22(金) 23:13:58

>>115
問題を正しく特定できてるのか?

0117デフォルトの名無しさん

2006/12/23(土) 00:10:24

>>116
とにかくアクセス違反で落ちたり、
const変数が書き換わったりするみたいです

もちろんマルチスレッドが原因かは特定できないのですが、
（ただ、ソースを見ると明らかにマルチスレッドを扱いきれてないです）
今、メモリ周りとかいろんな方面から数人で見ています。
もちろんデバッガ使ったりログ吐いたりはしています。

0118デフォルトの名無しさん

2006/12/23(土) 01:17:19

>>115

あと、EnterCriticalSectionへの再帰がないか。
同一スレッドだと、EnterCriticalSectionの挙動が変わるから注意。

0119デフォルトの名無しさん

2006/12/23(土) 03:03:16

どれくらいのスパゲッティ度かにもよるけども
仮想的なdbを用意して、データへのアクセスは必ずdb経由にするのも手だぞ。
（ポインタは渡さない、必ず生データのやり取りにする）
少なくとも知らない間に書き換わることはなくなる。
パフォーマンスは落ちるけどな。

0120デフォルトの名無しさん

2006/12/23(土) 09:02:59

>>118

なるほど、それは知りませんでした。ありがトン！！！！！

>>119

うーん、なるほど。それも覚えておきます。ありがトン！！！
とりあえず、ある程度安定してきたら、
再設計など検討するらしいです。

0121デフォルトの名無しさん

2006/12/31(日) 12:29:32

winapiでいうところのCrateEvent(), WatiForSingleObject(), SetEvent(), ResetEvent()
に該当する関数ってPOSIXでいうとどんなものになるんでしょうか？

mutexは双方にあって別にいいんですが、待機オブジェクトがなくて困っています。

0122デフォルトの名無しさん

2006/12/31(日) 13:24:29

>>121 condition

0123デフォルトの名無しさん

2007/01/04(木) 21:52:54

新年明けましておめでとうございます。
本年も、マルチスレッドプログラミング相談室その５にご健勝あれ。

0124デフォルトの名無しさん

2007/01/06(土) 21:53:22

本年の相談は終了いたしました。

0125デフォルトの名無しさん

2007/01/06(土) 23:09:40

>>123
うむ御旗楯無もご照覧あれ

0126デフォルトの名無しさん

2007/01/08(月) 22:40:26

実験用にものすごく単純なマルチスレッドの http サーバを組んでみたのだけど、
コードだけ見るとロックするようなコードじゃないのに、長時間ストップしたまま
になることがある。（いちおう、しばらく待つと再開する）

listen() 状態のソケット作って、accept() したら pthread_create() してループ。
子スレッドのほうでは GET (path) HTTP/1.1 を待って、そのファイルを読んで返すだけ。

という単純なやつなのだけど、毎秒100リクエスト以上くらい httperf で送ってやると、
必要以上に処理がストップする。
(netstat -a すると一つも ESTABLISHED になっていない状態で数秒間とまっている)

カーネルは NUMA を無効にした以外は特にいじっていない Linux 2.6.15.7/x86_64
スレッドとネットワークをがんがんいじっている人には自明な問題っぽいけど、
どの辺に原因があって、どういじれば、せめて無駄なストップをしなくなるのでしょうか。

0127デフォルトの名無しさん

2007/01/09(火) 11:26:21

>>126
親スレッドでpthread_joinなり、pthread_detachしてる？
してないと、終了コード保持のため、子スレッドが終了せず、プロセスのスレッド数限界に
引っかかるかもしれん。

0128デフォルトの名無しさん

2007/01/09(火) 17:27:41

いちいちaccept毎にthreadを作成・破棄というのが良くない予感

0129デフォルトの名無しさん

2007/01/09(火) 19:18:57

>>126
子スレッドはちゃんｊとソケットから全部読んでから closeするか、shutdown するかしてますか？

0130デフォルトの名無しさん

2007/01/09(火) 21:36:43

FreeBSDでコンパイル＆実行するとそういう問題は起きない

0131デフォルトの名無しさん

2007/01/16(火) 22:08:14

_endthreadでスレッド終了すると、デストラクタが走りません。
無理やり{}で囲んでデストラクタを走らせてますが、
標準的な方法ってありますか？

0132デフォルトの名無しさん

2007/01/16(火) 22:17:40

_beginthreadは使わない
_endthreadexは呼ばない

0133デフォルトの名無しさん

2007/01/16(火) 22:29:22

>>132
_beginthreadexを使い、スレッド終了時に_endthreadexを呼ばないで単にreturnするだけということでしょうか？？

0134126

2007/01/16(火) 23:37:42

ISP が割り当てるアドレスの周辺が 2ch にブロックされて書き込めなかった…。

スレッドとは関係なく、プロセス (もしくはある listen 状態のソケット)
あたりの同時接続数が一定値を超えると何かあるのかも、とか推測中。

>>127
pthread_detach() してますね。
>>128
待機スレッドを用意しておくとかすると改善するのかな。
>>129
あ、読み残しがある可能性はあるかも。
けど、そういう原因ならリクエスト頻度を下げても同様の問題が起こり
そうなものだが、 50リクエスト/秒くらいにすると起こらなくなる。
>>130
ソケット一般の問題じゃなくて Linux 特有の問題か…。

0135126

2007/01/16(火) 23:39:44

あ、とりあえず接続数を減らして、一接続あたりの転送量を増やすことで
目的には事足りるので、とりあえずそのようにしてやっている。

なぜストップするのか、に対する興味はあるのでまだ調べているけど。

0136デフォルトの名無しさん

2007/01/17(水) 18:05:57

tcp_fin_timeout の話かなぁ
再利用できるポートが足りなくなって、待ちになってるとか

0137126

2007/01/17(水) 22:48:11

>>136
あ、それビンゴかも。

Apache に細工して、一度ソケットを (勝手な手順で) 作り直してアクセスすると、
同様の停止現象が起こった調査結果が手元にある。

ソケットに何かの値を設定すると停止現象を回避できるのかなあ
(Apache は標準でそれをやっているけど、自分の勝手な手順ではやっていないのが原因かなあ)
と想像していた。 setsockopt() で *ソケットごとに* この tcp_fin_timeout を
設定できるらしいので、この値がそれかもしれない。

これから Apache のソースを読んでみるつもり。 thanks.

0138デフォルトの名無しさん

2007/01/17(水) 23:11:05

>>134
＞あ、読み残しがある可能性はあるかも。

ソケットは、両端で正しく
・全部読む (read で 0 が戻るまで)
・shutdown する
のどちらかをしないと、close しても FIN_WAIT_2 だか何だか長めに待たされるステートに
なっちゃっうんじゃ無かったかなあ。netstat してみれば即わかるけど。

ttp://www.kt.rim.or.jp/~ksk/wskfaq-ja/articles/debugging-tcp.html
の mini FAQ の 5 を参照。

0139デフォルトの名無しさん

2007/01/19(金) 12:09:34

スレッドがシグナル状態になったあとに新たにスレッドを生成したいのですが、
そのスレッドのハンドルはクローズした方が良いのでしょうか？
シグナル状態になったらスレッドのスタックは解除されるようですが。
上書きしてCreateThreadをしたらメモリリークしたりしますか？
Win32APIです。

0140デフォルトの名無しさん

2007/01/19(金) 12:36:33

クローズした方が良い

0141デフォルトの名無しさん

2007/01/19(金) 23:23:03

ハンドルってただのポインタだから、
上書きしてもポインタ先が変わるだけ
リソースは残ったままだとおもう

0142デフォルトの名無しさん

2007/01/19(金) 23:30:08

スレッドが終了してシグナル状態になったんであれば、
スタックとかコンテキストは解放されると思うけど
ハンドルは残ったままじゃないか？戻り値を受け取るためにハンドルが必要だし。
といっても、ハンドルごとき残ったままでもたいしたことは無い。
（少々のリソース漏れはたいしたことないなんて言ってる奴のコードは信用ならんけど）

0143デフォルトの名無しさん

2007/01/20(土) 01:01:12

試してみた。
#include <stdio.h>
#include <windows.h>
static DWORD WINAPI func(LPVOID p) {
printf("thread %d\n", (int)p);
return 0;
}
int main() {
int i;
for(i = 0; ; i++) {
if (::CreateThread(0, 0, func, (LPVOID)i, 0, 0) == 0) break;
}
::getchar();
printf("i = %d　error code %u\n", i, ::GetLastError());
::getchar();
}

VS2005のデバッガ上だと2000超えたあたりでERROR_NOT_ENOUGH_MEMORYで止まる。
デバッガ外でやってみたら10万超えても終わらず、
なぜかipoint32.exeにアプリケーションエラーが出たりして怖くなったのでやめた。

0144デフォルトの名無しさん

2007/01/21(日) 13:15:48

メモリリークか何もかも（ｒｙ

0145デフォルトの名無しさん

2007/01/21(日) 15:01:28

func のスレッド優先度、上げといた方がいいのでは?

0146143

2007/01/22(月) 08:17:30

あーそっか。あくまでハンドルのみのテストだったらちゃんとWaitForSingleObjectで待たなきゃいかんわな。
しかしWaitForSingleObjectしたのにわざわざCloseHandleしないでおく理由って考えにくいが。

0147 ◆0uxK91AxII

2007/01/22(月) 19:48:12

CreateThreadで走らせたthreadでは、CRTのfunctionを呼ぶべきではない。

0148デフォルトの名無しさん

2007/01/22(月) 20:37:55

メモリーリーク？

0149デフォルトの名無しさん

2007/01/23(火) 00:11:40

再入？

0150デフォルトの名無しさん

2007/01/23(火) 01:46:25

ttp://d.hatena.ne.jp/NyaRuRu/20070113/
こんな話もあった。

0151デフォルトの名無しさん

2007/01/24(水) 19:22:25

とりあえずCRTは動的リンクしておけと

0152デフォルトの名無しさん

2007/02/02(金) 23:38:46

2つプロセスで共有メモリのデータを共有する
サンプルってどこにあるのですか？pthread Linuxのやつを探しています。

0153デフォルトの名無しさん

2007/02/03(土) 09:49:27

スレッド関係ないから。APUE買え。

0154デフォルトの名無しさん

2007/02/03(土) 10:21:08

VS2005って標準でOpenMP使えたんだな

0155デフォルトの名無しさん

2007/02/18(日) 16:38:41

ここで俺がひとまずここまでのレスをまとめる。

マルチスレッドは　ム　ズ　カ　ス　ィ

0156デフォルトの名無しさん

2007/02/18(日) 20:05:23

>>152
だまってmmapすればいいんでないの？

0157デフォルトの名無しさん

2007/02/18(日) 21:12:05

>>155
お前にこの言葉を授けよう
「糞スレ立てるな」

0158デフォルトの名無しさん

2007/02/20(火) 23:27:34

ファイアーモックス!

0159デフォルトの名無しさん

2007/02/24(土) 10:27:57

質問なんですがマルチスレッドでは同じ変数のアドレスの場所を
if文等で見に行くだけならぶつかることはないですか？

0160デフォルトの名無しさん

2007/02/24(土) 10:34:52

読むだけなら問題ないと思。
最適化には気をつける必要があるが。

0161デフォルトの名無しさん

2007/02/24(土) 10:40:11

FAQだな。
読むだけなら排他不要。
ただしvolatileを忘れずに。

つーかvolatile最強。

0162デフォルトの名無しさん

2007/02/24(土) 12:17:45

>>159-161
別スレッドからの書き込みも考慮するならロックなどによる同期が必要。

volatile はネタだよね？

0163デフォルトの名無しさん

2007/02/24(土) 12:46:43

他スレッドが変更するメモリを読むなら必要でしょ。

0164デフォルトの名無しさん

2007/02/24(土) 13:02:15

おっ久々にvolatileが来たか。わくわく。

0165デフォルトの名無しさん

2007/02/24(土) 13:16:54

>>162
writerが一人、readerが複数ならロックする必要ないよ。

0166デフォルトの名無しさん

2007/02/24(土) 13:28:17

>>165
あたまだいじょうぶか

0167デフォルトの名無しさん

2007/02/24(土) 13:28:40

意地悪しないで教えてやれよって。
JavaやC#でのvolatileはその解釈であってる。
C/C++のvolatileは割り込みしか想定していないので、マルチスレッドでの動作は不定。
ただしシングルCPUでのマルチスレッドは割り込み(タイマー割り込み)で実現されているのでたまたま動作する。

>>165
変数がアトミックじゃない場合、例えば32bitCPUで64Bitの変数にアクセスする場合などは、
書いてる最中に読み込みされると半分しか書き換わってない状態を読み込む可能性がある。

0168デフォルトの名無しさん

2007/02/24(土) 13:34:19

シングルCPUのマルチスレッドだと動いてしまうことが多いからね。それで合ってると思い込んでしまうのだよ。
ＣＰＵキャッシュの問題は難解だね。
さらにウィークメモリモデルともなるとさすがについて行けんorz

0169デフォルトの名無しさん

2007/02/24(土) 13:43:29

書き込み側が明示的に、アトミック書き込み命令を出せばいいんでね？

0170デフォルトの名無しさん

2007/02/24(土) 16:37:41

読み込みもアトミックじゃねーと意味ね-よ

0171デフォルトの名無しさん

2007/02/24(土) 16:41:40

要は、アトミックに読み込めることが期待できるint程度のデータ以外はなんらかの排他が必要ということでよろしいか。
#いや、intでも排他するべきなのかもし煉瓦。

0172デフォルトの名無しさん

2007/02/24(土) 18:52:05

>>171
> #いや、intでも排他するべきなのかもし煉瓦。
というのが>>168だね

マルチCPU環境の排他はバス設計の影響もうけるから
環境を明記しないと言及不能やね

0173デフォルトの名無しさん

2007/02/24(土) 20:21:33

>170
書き込みがアトミックに出来るのに、読み込みがアトミックに出来ない、なんて
変態CPUが現存するのか？そういうCPUではロックをどう実装するんだろ？

0174デフォルトの名無しさん

2007/02/24(土) 23:09:38

キャッシュラインをまたぐと面白いよねー

0175デフォルトの名無しさん

2007/02/25(日) 01:29:43

＞書き込みがアトミックに出来るのに、読み込みがアトミックに出来ない、なんて
＞変態CPUが現存するのか？

＞書き込み側が明示的に、アトミック書き込み命令を出せばいいんでね？
↓
＞読み込みもアトミックじゃねーと意味ね-よ

だれも読み込みがアトミックにできないなんて言っとらんわ。

0176デフォルトの名無しさん

2007/02/25(日) 04:26:18

どっちかというと
＞ねーと　 → ー
＞ね-よ　　→ -
この不整合の方が気になるな
どちらかがアトミックじゃないのかもしれない

0177デフォルトの名無しさん

2007/02/25(日) 05:04:12

こういう意味不明な誤変換はUNIX発のFEPwに多いな

0178デフォルトの名無しさん

2007/02/25(日) 15:04:49

volatile方式を知られては困る奴が必死だなｗ

0179デフォルトの名無しさん

2007/02/25(日) 15:39:00

http://d.hatena.ne.jp/yupo5656/20040618
volatile無意味説

0180デフォルトの名無しさん

2007/02/25(日) 17:24:44

そのリンク先にしても、なぜvolatileでは駄目なのかが書いてなくて
「お母さんが駄目って言ってたから」レベルの話しか書いてないな。
そして、そのURLを貼る>>179も同様。

0181デフォルトの名無しさん

2007/02/25(日) 17:50:33

なぜ volatile で済むと言えるのか、書くかリンク貼るかしてみやがれ。

0182デフォルトの名無しさん

2007/02/25(日) 18:59:13

volatile - Multithreaded Programmer's Best Friend
http://www.ddj.com/dept/cpp/184403766

0183デフォルトの名無しさん

2007/02/25(日) 19:32:05

>>182
もしかして >>181 へのレスのつもりなのか？

0184デフォルトの名無しさん

2007/02/25(日) 19:41:48

そんなわけないだろ。逆だ。
"Paradoxically, it's worse to use volatile directly with built-ins, in spite of the fact that initially this was the usage intent of volatile!"

0185デフォルトの名無しさん

2007/02/25(日) 20:20:26

>>182
これって
＞スレッドセーフなメソッドにはvolatileをつける。
という提案だよな？まだ実装はないと思ったのだが。

0186デフォルトの名無しさん

2007/02/25(日) 22:48:59

volatileを実装してるJVMってほとんど無いんじゃなかったっけ

0187デフォルトの名無しさん

2007/02/25(日) 23:35:03

>>185
実装ってどういうこと？標準 C++ コンパイラがあれば使える手法に見えるんだけど。

0188デフォルトの名無しさん

2007/02/26(月) 01:31:15

C とか C++ の volatile って I/O レジスタとか, 割り込み同期変数とかを, オ
プティマイザがレジスタキャッシュしないように指示するために導入された物で,
バリア同期命令とか生成する処理系は皆無のような気がするが...

俺の認識が古くって, バリア同期とか生成してくれる処理系が既にあるんだった
ら先にあやまっとく

0189デフォルトの名無しさん

2007/02/26(月) 05:30:32

何故「volatileで済む用途」のケースにメモリバリアがどうのという話になるのかわからんね。

簡単な例で言えば
(タイマ割り込み等で更新される)カウンタを読む場合とか
複数スレッドで値を読み取るとしても、ロックする必要なんか無い。
たとえ1ns更新が遅れたって、問題が出ることは無い(問題が出るようなら、設計がおかしい)。

え、更新時の再入を考慮しろって？
そういうのを「設計」と言うんだろうに。

0190デフォルトの名無しさん

2007/02/26(月) 06:29:25

>>182
int func() const { } はよく使うが、int func() volatile { } を実際に使ってる例ははじめてみる。
ただその記事のLockingPtrは func() volatile の仕組みだけ拝借して実際の排他はmutexでやってるようだ。
よく理解できない部分もあるがvolatileしておいてconst_castで限定的に穴あけてるのだろうか。
このスレで問題になるのはそこではなくて、
記事の最初と２番目のコードで　while (!flag_)　のflagがvolatileだけでいいのか、
同期機構を使わなくてはいけないかのポイントだと思う。

0191デフォルトの名無しさん

2007/02/26(月) 07:52:54

>>188
volatileで済むってのは、コヒーレントキャッシュを持っている環境で
アトミックに読み書きできるサイズ限定だから、メモリバリアは関係ないよ。
2つ以上の変数に依存関係があったら、volatileだけでは無理。

一般論の話をすれば、キャッシュの一貫性を保障しない環境もあるから
int程度でもvolatileでは駄目という話になるが。

0192デフォルトの名無しさん

2007/02/26(月) 09:15:17

ちゃんと読めてないが、>>182って、コンパイラの実装とか関係なくて
constみたいな印としてvolatileを使ってみようっていう提案だよね？

0193デフォルトの名無しさん

2007/02/26(月) 19:26:29

volatileの仕様は処理系定義だとあれほど言ってるのに…

処理系を指定しないでvolatileについて語れることはない

0194デフォルトの名無しさん

2007/02/26(月) 21:25:32

処理系どころか言語すら指定されてない気がするのは
漏れだけではないはずだ

0195デフォルトの名無しさん

2007/02/27(火) 00:02:42

とりあえず、volatileをCの最適化阻害だけと仮定して、

>>191
一貫性を保証しなかったとしても、それはあくまで保証の話。
いつまで経っても同期されないような腐ったCPUってあるの？
あったとしたら処理系としてBrokenだよなぁ・・・。

>>193
ここに書いてる人のほとんどは処理系依存だなんて承知の上でしょ？

とりあえず、intだとしても同期やメモリーバリアは必要か？
って問いはもう少しレベル分けした方がいいと思う。

1. 読み込みに依存した書き込み(read-modify-write)
⇒ 同期もしくはメモリーバリアを含んだCASが必要。

2. 読み込みに依存しないが、確実に更新を見る必要がある
⇒ OoOを回避するために、少なくともメモリーバリアは必要。

3. 読み込みに依存しないし、更新は近いうちに反映されればよい
⇒ volatileでレジスタへの張り付きを阻害するだけで問題なし？

>>189の「更新が遅れても構わない」は3になると思うんだが。

0196デフォルトの名無しさん

2007/02/27(火) 01:19:13

つまり、例えば時間掛かる処理をするスレッドがあってその進捗をプログレスバーに出すような用途なら、
進捗を書き込むのを処理スレッドに限定してGUIスレッドでそこをvolatileで参照するのもありってことでOK?

0197デフォルトの名無しさん

2007/02/27(火) 01:57:30

マルチスレッドの話は環境によって差異がありすぎるから
環境を限定しない討論に何の意味もないって感じだな。

0198デフォルトの名無しさん

2007/02/27(火) 03:01:55

volatile最強伝説が吹き荒れるｗｗｗ

0199デフォルトの名無しさん

2007/02/27(火) 08:43:30

> 195
> とりあえず、volatileをCの最適化阻害だけと仮定して、

曖昧な仮定だな。
まずはお前の想定している処理系と、そのマニュアルにある
volatile参照の仕様を書くんだ。

0200デフォルトの名無しさん

2007/02/27(火) 09:11:34

もう>>182みたいにvolatileキーワード使って組込型でも何でもロック必須にしちゃいなyo!
template <typename T>
struct NativeWrapper
{
operator T&() { return obj; }
private:
T obj;
};

volatile NativeWrapper<int> syncint;
mutex mtx;
LockingPtr<NativeWrapper<int> > pInt(syncint, mtx);
*pInt = 10;

0201195

2007/02/27(火) 12:18:08

>>196
そんなとこ。他ではTwo-Phase Terminationの終了フラグとか。
こちらの場合はメモリーバリアを含んだ同期をループの内部で
実行する事が殆どだから、次のループで確実に気付くだろうけど。

>>197,199
おまえら処理系依存って書きたいだけだろ？
実際のとこはどうなのか、って話がしたいんだよ。

少なくともOoOやコヒーレンシが問題になるんだから、
最低限SMP/Multi Core/HT等のアーキテクチャとなる。

例えばIA-32,Power PC,Sparc等のSMPの類をサポートした
アーキテクチャのうち、>>195よりも厳しい制約が必要と
なるものは存在するの？

0202デフォルトの名無しさん

2007/02/27(火) 13:04:58

>>201
個々の CPU について考えるなんて面倒だから、
保証されてるかどうかで話したほうが楽なのに。

今は無くても将来にわたって無いとも言えないしね。

0203デフォルトの名無しさん

2007/02/27(火) 14:04:14

>>193
データ構造上の都合か何かでキャッシュラインをまたぐような位置から
int を読み込む場合には 3 もだめじゃないかな。

0204デフォルトの名無しさん

2007/02/27(火) 14:12:43

>>201
Intel Itanium では、非共有キャッシュが大きい上にキャッシュフラッシュの順序が
書き込みの順序と異なる。ので、

・volatile int a を監視
・aが変更されたら「何か」を行う

という処理の場合、大抵は「何か」の準備が出来たから a を1にしてるんだと思うけど、
メモリバリアが無いとその準備の処理結果を読み出せない可能性がある。

例） volatile size_t buflen; volatile char buf[max_buf]; で、
スレッド1:　buflen = read(hoge); ...
スレッド2:　if (buflen>0) { bufを利用; }
で、（スレッド2側のCPUから見て）buflen には read の結果のバイト数が書かれているが、
buf の内容はデタラメ、という状況がごく当たり前にあり得る。

0205195

2007/02/27(火) 14:54:42

>>203
キャッシュラインをまたぐ場合って、普通のコードじゃ起きないし、
char buf[sizeof(int)+1]; *(int *)(buf+1) = 0;した場合とかでしょ？
今では例外飛ばさずにアクセスできるアーキテクチャの方が少数派なのでは？

>>204
他の変数を確定的に見る必要がある場合はOoOの関係で無理。
>>195はひとつのintを扱う場合なつもりで書いてます。

>>196を例にすると、タイマでプログレスバーを更新する時はvolatileのみ、
最後に終了したかを確定的に判断したい時だけpthread_join()するケースとか。

0206デフォルトの名無しさん

2007/02/27(火) 15:21:57

>>205
PCで使われているCPUの98%は、それをごく普通に実行します。
任意位置からの32bitの整数読み出しはMPEG系のビデオコーデックの
処理では多利用されるし。

0207195

2007/02/27(火) 16:11:02

CPUの数が多いのは当たり前だからアーキテクチャって書いたのに。
そんな下らないツッコミは要らないって。。

Codecの処理だろうが、境界整列に反したメモリアクセスなんて
行儀の悪いコードなんじゃないの？少なくともポータブルじゃない。
処理系依存のレベルで言ったらvolatileの比じゃないと思うんだけど。

0208デフォルトの名無しさん

2007/02/27(火) 16:25:35

アーキテクチャの数で言って多いか少ないかについては、
漏れは何も言っていません。

実存するシステムの大半では割合で例外は飛ばないという
（関連する）別の事実を提示しただけですよ。

0209195

2007/02/27(火) 18:33:40

>>208
おまえ例外が飛ばないって書きたいだけだろ？
実際のとこはどうなのか、って話がしたいんだよ。

0210デフォルトの名無しさん

2007/02/27(火) 19:55:55

理屈で勝てそうにないと急におまえ呼ばわりですか。

実際の例で言うなら、MPEGのシステムストリームから4バイト長さの整数を取り出すとき、
ポータビリティを重視している ffmpeg ではバイト単位で取り出して整列してますし、
IA32/64が前提のIPPではポインタをそのままデリファレンスしてアライメントを気にせずに整数を取り出してます。

「普通のコードじゃ起きないし、例外飛ばさずにアクセスできるアーキテクチャの方が少数派」だから、
キャッシュラインまたぎの問題は無視してよいとでも言いたげな感じですが、
実際のとこどんなプログラムをどれだけ調べた上で書いてるんですか？

0211デフォルトの名無しさん

2007/02/27(火) 20:59:04

IA86において、そもそも、アラインメントが狂った位置への
アトミック書き込みはできない。

0212デフォルトの名無しさん

2007/02/27(火) 21:54:58

傍から見てるモノとしては
実装の詳細じゃなくてアーキテクチャの視点で語ってほしいです><

0213デフォルトの名無しさん

2007/02/27(火) 22:12:28

「相談室」なんだから、なにか適当なターゲットを想定するのが普通だろ
メタ論がやりたいならどっか適当にスレ立てろよ

これがほんとにマルチスレッド

0214デフォルトの名無しさん

2007/02/27(火) 23:34:05

そういうアクセスははなからそういうあくせすという前提で特別に処理を書くんじゃないの？
intでもアトミックに読めないとか、そういう問題とは別次元だろ。

0215デフォルトの名無しさん

2007/02/27(火) 23:35:07

わざとあえて意識してそういうことをしないとそういうことは起こらない。

0216195

2007/02/28(水) 01:26:31

>>210
>>209は自分じゃないんで・・・。

他の方も書いているように、CodecみたいにCPUベタベタな
最適化を行う場合を考えてもしょうがないかと。

今のところは>>189や>>196みたいなケースの場合にvolatileで
不十分な証拠は(処理系依存を除いて)出ていないんじゃないですか？

そんなわけで、今のところ>>180から進展はなさそうに思います。

>>213
自分はPCサーバクラスで使われるCPU辺りをメインに書いてます。
今はノートですらDual Coreだったりするので、その辺りも含めて
昔で言うワークステーションクラスまででしょうか。

0217デフォルトの名無しさん

2007/02/28(水) 02:53:24

言語組み込みの volatile で全部済ませられると主張するなら、
「あぁそうだといいね」とも思えるが、場合によってはロックが必要なことは
理解しているようだし。そうなると細かいこと考えずに全部ロックしとけば
いいと考えそうなもんだ。

なんでそんなに必死になってまでロック使いたくないの？
わざわざ保証されてないコード書くメリットが何かあるの？

0218デフォルトの名無しさん

2007/02/28(水) 06:28:24

このスレは頭ごなしにmutex使えやゴラーというやからが多いから意固地になってるのだろう。
結論はそうなんだけど、そこに至る過程を検証したいというのも分からないではない。
mutexの中の人が何をやっているかとか、実際身近にあるＰＣで賢い小人さんがどう働いているかとか、
そういう話題なら問題は無いだろう？

0219デフォルトの名無しさん

2007/02/28(水) 13:20:29

>>217
>なんでそんなに必死になってまでロック使いたくないの？
実行コストに決まってるだろ。
実行コスト無視できるなら、スピンロック、read-writeロック、プロセス内Mutex、プロセス間Mutex、
の使い分けなんて必要ない。
ただ、volatileで生成されるコードと、他のロックでどちらがコストが高いかは知らん。実行系によるし。

0220デフォルトの名無しさん

2007/02/28(水) 13:51:46

スレッド間で変数を共有する場合問題になるのは次の４つくらいか。
1)変数のレジスターへのキャッシュ。
2)コンパイル時の命令の並び替え。
3)CPUによる命令の並び替え(out of order)
4)CPUキャッシュ間の非同期。

1,2はコンパイラの仕事。
3は単一CPUでは発生しない。マルチCPUでは両方のケースがある。
4は単一CPUでは発生しない。マルチでもコヒーレント(一貫性)が保障されている処理系が多い。
3,4が発生しないでメモリー更新の順番が正しく見える構成をstrong memory orderと呼ぶ。

volatileだと1,2でかつアトミックな操作ができる単独の変数のみ。
メモリバリアは1,2,3,4すべてを満たしていて、
同期系のファンクションを使えばメモリバリアは適切に適用される。
書き込みが１スレッドで多数の読み込みスレッドがある場合に通常のLockが負荷が高いようなら、
ReadWriteLockとかInterLockとかそういったものを検討すべきだろう。

0221デフォルトの名無しさん

2007/02/28(水) 13:57:54

>>195
＞いつまで経っても同期されないような腐ったCPUってあるの？
＞あったとしたら処理系としてBrokenだよなぁ・・・。

ないとは言い切れない。互換性、安全性をとるなら同期ファンクションを使っておこう。
windowsXPまではstrong memory orderを前提にしているらしい。
MSDNのvolatileの説明が変なのはこのためだろうか。
移植性を無視してターゲットを絞るなら独自にいろいろやるのもありかもしれないが、
windows2003(今のところItanium用だけらしいけど)からは上記の3,4があるweak memory orderも
視野にいれているらしいから、こういうヴァージョンアップ時に困るな。

0222デフォルトの名無しさん

2007/02/28(水) 17:09:18

組み込み用だとキャッシュの同期なんて全くしない環境もあるようだが、
（そもそもCPUがマルチプロセッサ用に作られていない）
そういう環境にマルチスレッド対応のOSが移植されてるかは、
ググってみたが見つからなかったな。

一昨年あたりから、組み込み用CPUでもキャッシュ同期メカニズムを
持った物が出てきたようで、SMP対応のlinuxが移植されてたりするけど。

0223195

2007/02/28(水) 17:27:11

>>218
ほぼそんなとこです。

あとは、なんでPOSIX ThreadsにCASがないのか、とかね。
プリミティブ志向な設計なんだから追加されてもいいのに。
有名どころのアプリのいくつかは自前で実装してたりするし。

>>221
そりゃないとは言い切れないでしょ。

でもそういうのって、二の補数表現や1byte=8bitを仮定して
プログラムを書くのは良くないってのと同じなんじゃないの？
1word=36bitみたいな変態アーキテクチャを相手するのと一緒。

0224デフォルトの名無しさん

2007/03/01(木) 00:19:15

_beginthreadの使い方について質問です。
子スレッドの処理が止まっているとき、終了する方法が知りたいです。

-----------------------------------------------------------------
//子スレッドの関数
void thread_func(){
//Sleep();やソケットのaccept関数など永久に待つ関数などで、
//処理が止まっているので終了状態になりません
}
//子スレッド呼び出し
thread_id = _beginthread(thread_func,0,(void *)param)
//終了処理
GetExitCodeThread( thread_id,lpExitCode );//終了コード取得
ExitThread(lpExitCode );//終了コード指定して終了
CloseHandle(thread_id);//ハンドル閉じる
-----------------------------------------------------------------
１、子スレッドのsleep、accept関数など待ち状態を、解除する方法あるでしょうか？
処理が進めば、_endthreadで終了することが出来きるのですが。

２、強制的に親スレッドから、安全に子スレッドを強制終了する方法あるでしょうか？
_beginthreadは、CreateThreadを呼んでるみたいなのですが、上記のように
"//終了処理"しても大丈夫でしょうか？安全な方法教えていただけないでしょうか。

よろしくお願いします。

0225デフォルトの名無しさん

2007/03/01(木) 00:19:22

>>223
なんで良くないと言われていることをわざわざやりたがるの？

0226sage

2007/03/01(木) 00:43:41

>>225
良くないって、仕様で未定義だからってだけでしょ？
検証もせずに「お母さんが駄目って言ってたから」な方が嫌。

0227デフォルトの名無しさん

2007/03/01(木) 01:06:04

>>226
最近のレスでロック API の仕様の根拠となるものはあらかた提示されたんじゃないの？

0228デフォルトの名無しさん

2007/03/01(木) 01:22:09

>>224
とりあえず、
・必要なら、子スレッドでは極力タイムアウトするAPIを使う
・_beginthread()の場合、スレッド関数の戻りで子スレッドのハンドルは自動開放されるので
　明示的に開放する必要はない
・少なくとも_beginthread()のハンドルにCloseHandle()を使うのは間違い
　きちんと対応する関数をセットで使わなければいけない
・ただ、親スレッドでExitThread()したら、その後のCloseHandle()は実行されないよ
・子スレッドの安全な中断方法はない。

突っ込み所満載すぎるので、MSDNなりナニなりよく読むべし。

0229デフォルトの名無しさん

2007/03/01(木) 03:23:13

>>228
タイムアウト処理を考えるという方針でいきたいと思います。

sleepは時間を短くすればいいですし、
acceptは、selectを使ってrecvのタイムアウト関数（timeoutRevcとします）
と同じにすれば、timeoutAccept関数作れるかもしれないです。
・timeoutAccept抜けたら、はじめの一回目は、ソケットが読み込めるのわかってるので普通のrecv関数を呼ぶ。
・次の受信から、timeoutRevc呼ぶ感じでしょうか。

いくつも箇条書きでアドバイス、ありがとうございました。

0230デフォルトの名無しさん

2007/03/01(木) 07:04:23

229です。
acceptする前に、select関数使えないんでしょうか。

FD_ZERO(&readfds);
FD_SET(soc,&readfds);
select(width,&readfds,NULL,NULL,&timeout)
socは、きちんと渡せていたんですが、接続試しても
select抜けられずに、全部タイムアウトになります。
accept呼んでからじゃないと、ソケットの読み取り可能か
わからないかもです。

スレ違いになりますので、ネットワークのスレに行きたいと思います。
ありがとうございました。

0231デフォルトの名無しさん

2007/03/01(木) 11:14:25

やべーvolatile最強すぎる

「volatileが最強でない環境って存在するの？」
「現存しないからvolatile最強ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

>>161 でFA出てるしｗｗｗ

0232デフォルトの名無しさん

2007/03/01(木) 11:18:50

2000年問題に通じるものがあるな

0233デフォルトの名無しさん

2007/03/01(木) 12:28:10

[すれ立てるまでもない質問はここで]
で聞いてたんだが、此処で聞いた方が良いかと思ったので、
再質問させてもらいます。

Windows MFCでマルチスレッドは止めておいた方が良い
と、良く聞くんだけど、具体的にどんな問題が発生するのか
掲示しているところが無いんだけど、どうしてMFCでの
スレッドは嫌われるのか教えてもらえないでしょうか。
単なる好奇心なので、仮説でもうれし。

0234デフォルトの名無しさん

2007/03/01(木) 12:42:43

誰が言ってんだ、そんなこと。

0235デフォルトの名無しさん

2007/03/01(木) 12:48:10

>>233
それま色々なスレで同じ質問をしないほうが良いと言われただけでは？

0236デフォルトの名無しさん

2007/03/01(木) 12:50:14

>>233
とりあえず移動元に誘導書いておけよ、マルチ扱いされるぞよ。
俺も聞いたことない。

0237デフォルトの名無しさん

2007/03/01(木) 13:27:04

MFCに限らず、マルチ(複数の)スレッドで質問するのは良くない。

0238デフォルトの名無しさん

2007/03/01(木) 14:21:41

ﾜﾛﾀ

0239デフォルトの名無しさん

2007/03/01(木) 16:05:38

>>224
つ http://support.microsoft.com/kb/254956/

0240233

2007/03/01(木) 16:17:27

>>234
>MFC のシステムそのものがマルチスレッドに向いていない。
ttp://www.kab-studio.biz/Programing/PragmaTwice/Main/292.html
さすがにどこで見たかを思い出せなかったので検索して
出てきたのが例えばこれとか。

>>236
>>237
移動元に書いてきたよ。
ごめんよ。

0241デフォルトの名無しさん

2007/03/01(木) 17:05:31

>>240
WaitForSingleObjectで待つんじゃなくて自イベントで通知
MFC関係なくないか？
読みづらいし会話式がアレだな

0242デフォルトの名無しさん

2007/03/01(木) 17:17:57

ＵＩスレッドは確かに使わないかもしれない。向いてないとか難しいとかいうより必要性が薄い。
ワーカースレッドについては特にMFC特有の問題じゃないな。

0243デフォルトの名無しさん

2007/03/01(木) 18:03:52

>>240
じゃあ、そのサイトが間違い。
いや間違いというか、MFCがマルチスレッドに対して便利な機構を用意しているかというとNoだけど、
マルチスレッドを意識してないわけじゃない。つまり、ユーザーからロックできないグローバル変数、
クラス変数はロックしてる。
なんで、ユーザーからロックできる部分については、勝手にロックして、スレッドセーフにしろよ、
ってスタンス。それを「向いてない」と表現するかどうかは人による。
・MFCとマルチスレッドの関係 (Afx...でのMFCグローバル情報へのアクセス等)、
・Win32とマルチスレッドの関係 (SendMessageがらみのウィンドウループの把握、WinSockでのWM_を使った非同期処理等)、
・一般的なGUIシステムにおけるマルチスレッドの作法 (GUIスレッドを止めない、長時間処理は別スレッド、非同期化等)
を分けて考えるべき。

0244デフォルトの名無しさん

2007/03/01(木) 18:24:21

まぁMFCはガベコレがないという致命的欠点を持っているなんて
Wikipediaに書かれるほど挫折した連中に嫌われているってことだな。

0245デフォルトの名無しさん

2007/03/01(木) 18:47:00

> それを「向いてない」と表現するかどうかは人による。
「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？
「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。

>まぁMFCはガベコレがないという致命的欠点を持っているなんて
これは笑いどころですか？

0246243

2007/03/01(木) 19:03:59

>> それを「向いてない」と表現するかどうかは人による。
>「俺はマルチスレッドなプログラムなんかできないから、ライブラリか何かでどうにかしてくれよ」という人？
>「これさえ使えばあら不思議。マルチスレッドなプログラムが簡単に！」とか。

いや、俺に言われても。

0247244

2007/03/01(木) 19:38:14

>>245
> これは笑いどころですか？

いや、俺に言われても。

0248244

2007/03/01(木) 19:57:04

>>247
いや、そこで騙られても。

0249デフォルトの名無しさん

2007/03/01(木) 21:02:37

MFCにガベコレを求めるとかバカとしか思えない

0250デフォルトの名無しさん

2007/03/01(木) 21:11:36

244はそんなことを言ってるわけじゃないんだが。
改行位置のせいで勘違いするのも分からんでもないが。

0251デフォルトの名無しさん

2007/03/01(木) 21:27:35

このスレのガベージをコレクトしたい

0252デフォルトの名無しさん

2007/03/01(木) 22:08:15

　　　　　　　／　＿＿＿＿ヽ　　　　　　　　　／￣　　￣＼
　　　　　　　|　 | /, －､, -､ｌ　　　　　　　　 /､　　　　　　　　ヽ
　　　　　　　| _|　-|　･|<　||　　　　　　　　 |･ |―-､　　　　　　 |
　　 , ―-､　(6　＿ｰっ-´､}　　　　　　　ｑ -´　二ヽ　　　　　 |
　　 |　-⊂)　＼ヽ_ ￣￣ﾉﾉ　　　　　　　　ﾉ＿　ー　 |　　　　　|
　　 |￣￣|／（_ ∧￣ / ､　＼　　　　　　　＼.￣｀　 |　　　　/
　　ヽ　　｀　,.|　　　￣　　|　　|　　　　　　　　O＝＝＝＝＝ |
　　　｀－ ´ |　　　　　　　| ＿|　　　　　　　　/　　　　　　　　 |
　　　　　　　　|　　　　　　（t 　）　　　　　　　/　　 /　　　　　　|
「>1からマークスイープでGCするよ！」　　　「コンパクションも忘れずにね」

１時間後…

　　　　　　,-――-､　　　　　　　　　　　　　　　　　　　　　　　　＿＿＿
　　　　　 { , -_－_－　　　　　　　　　　　　　　　　　　　　　／　　_ 　　_ ヽ
　　　　　.(6（ /),(ヽ|　　　　　　　　　　　　　　　　　　　　　/　 ,-（〃）bヾ）､l
　　　／人ー- ソヽ＿　　　　　　　　　　　　　　　　　　 |　/三 U 　|~ 三|_
　／　 /　 | ￣_∧／　　ヽ　　　　　　　　　　　　　　　　|（__.）―-､_|＿つ_）
　　　 | |　＼/_/-､　　　/　　　　　　　　　　　　　　　 /　 /｀ー--―-´ /
　　　 |-＼ _|_ ）＿|　　 /　　　　　　　　　　　　　　　　|　 //￣（ｔ）￣/
　　　ヽ-|￣|　 |＿|_ /　　　　　　　　　　　　　　　,－ |　　 | ヽ二二/⌒l
　　／　 l―┴､|＿＿)　　　　　　　　　　　　　　　|　（＿＿＞ -―（＿ﾉ
　／　　　｀-―┘ /　　　　　　　　　　　　　　　　　｀- ´
　　　　　　　　 /
「>1しか残らなかった…」　　　　　　　　　　　　　　　「テンプレへのリンクもなかったのか！」

0253デフォルトの名無しさん

2007/03/01(木) 22:48:55

>>251
　　　　　[ﾟдﾟ]　　・・・？
　　　　/[＿]ヽ
　　　　　|　|

0254デフォルトの名無しさん

2007/03/01(木) 23:53:37

>>253
おまえは呼んでない

0255デフォルトの名無しさん

2007/03/04(日) 02:15:45

pthreadのPTHREAD_MUTEX_INITIALIZERのように、
win32のCRITICAL_SECTIONを静的に初期化する方法はありますか。

現在は仕方が無いので
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
で済むところを
static pthread_mutex_t mutex;
static int initialized;
static int lock;
if (!initialized && InterlockedIncrement(&lock) == 1) {
　　pthread_mutex_init(&mutex, 0);
　　initialized = 1;
}
などと書きました。

なお、↑のコードでは、とりあえず
#define pthread_mutex_t CRITICAL_SECTION
#define pthread_mutex_init(A,B) InitializeCriticalSection(A)
#define pthread_mutex_lock(A) (EnterCriticalSection(A), 0)
#define pthread_mutex_unlock(A) (LeaveCriticalSection(A), 0)
#define pthread_mutex_destroy(A) DeleteCriticalSection(A)
などと定義しています（極めてうさんくさいですが）。

0256デフォルトの名無しさん

2007/03/04(日) 04:38:29

>>255
class CriticalSection
{
    CRITICAL_SECTION csect;
public:
    CriticalSection() { InitializeCriticalSection(&csect); }
    ~CriticalSection() { DeleteCriticalSection(&csect); }
    void Lock() { EnterCriticalSection(&csect); }
    void Unlock() { LeaveCriticalSection(&csect); }
    operator LPCRITICAL_SECTION() { return &csect; }
};

class Lock
{
    CriticalSection& save_cs;
public:
    Lock(CriticalSection& cs) : save_cs(cs) { save_cs.Lock(); };
    ~Lock() { save_cs.Unlock(); }
};

0257デフォルトの名無しさん

2007/03/04(日) 04:40:47

static CriticalSection cs1; // で初期化しておいて下のように使える。

void func(){
    Lock lock(cs1);
    //
}

void func(){
    cs1.Lock();
    //
    cs1.Unlock();
}

0258デフォルトの名無しさん

2007/03/04(日) 05:07:50

というやり方だと、
コンパイラの吐く「ローカルな静的変数の初期化コード」に排他処理が行われないため
グローバル変数(staticメンバでも良いが)にしか使えない。

で、過去スレに書いたが
CriticalSectionへのポインタとInterLockedExchangePointerを使えば
ローカルな変数でも、排他しながらの初期化及び実行が行える。

0259デフォルトの名無しさん

2007/03/04(日) 05:21:53

なるほど。C++のstatic objectの初期化機能を利用する訳ですね。
Cでは使えないテクニックですね……。

>>255のコードには不備がありました。
2コ目以降のスレッドがInitializedCriticalSection()実行前に
下に流れてしまう可能性があるので、
上のコードの後で
while (!initialized) Sleep(1);
としなければなりませんね。

0260デフォルトの名無しさん

2007/03/04(日) 05:48:19

>>258
＞で、過去スレに書いたが
目を通しておきたいのですが過去スレというのはこのスレですか？その４以前？

最初のロックまでCRITICAL_SECTIONの初期化を遅延したいとか
考えない限り大丈夫のように思えるけど。

0261デフォルトの名無しさん

2007/03/04(日) 05:48:40

んー、だから

static CRITICAL_SECTION *p = NULL;
if (!p) {
　CRITICAL_SECTION *q = new ...;
　Interlocked...(&p, NULL, q); //引数の順番忘れた
　if (p != q) {
　　delete q;
　}
}
EnterCriticalSection(p);
...
Leave...();

なら、Cでも使えるよ。

0262デフォルトの名無しさん

2007/03/04(日) 05:53:34

で、C++なら、これをclassにまとめて
#ifdef _WIN32 で切り分けてPTHREAD_MUTEX_INITIALIZERと使い分けると楽だよ。
ただ、必ずstaticなオブジェクトとして使わないといけない、ということを
分かった上で使わないといけないけど。

0263デフォルトの名無しさん

2007/03/04(日) 05:57:13

あ、Initializeとか忘れてたけど
まあ分かるでしょ

0264デフォルトの名無しさん

2007/03/04(日) 06:12:45

>>261
new, deleteがCでも使えるというのは冗談でしょう。

if (!p) {
　CRITICAL_SECTION *q = new ...;

これは、この部分に2コ以上のスレッドが同時に突入した場合、
2度以上InitializeCriticalSection()を実行させたいという意味ですか？

0265259

2007/03/04(日) 06:15:36

> while (!initialized) Sleep(1);

このように書きましたが、これはWin32環境で合法なのでしょうか。
マルチコアのシステムではまずかったりしますか。

MSVC++で-Ox最適化をかけたアセンブリコードを眺める限り、
一見動きそうに思えますが、いまいち自信がありません。

0266260

2007/03/04(日) 06:16:08

>>261
初期化を遅延する場合ですね。それなら了解。

0267デフォルトの名無しさん

2007/03/04(日) 07:08:09

>>264
newが使えない事くらい、わかった上で書いたんだけど(面倒だから)
そんな本質的じゃない部分を指摘してうれしい？

件の部分は、(ほぼ)同時に突入したら、当然複数初期化される。
けど、続く部分で、実際に代入されるのは一つであることが保証される。
(最初に実行されたスレッド以外からのCASは失敗する)
だから、それを実行した後、自スレッドで初期化した値とpが違っていたら
それを破棄して、全スレッド共有の値でロックを実行すればよいだけ。

まあ、俺が偉そうな事言いたくて書き込んだだけだから、あまり気にするな。
普通に非ローカルな静的変数とC++のインスタンス初期化を使うのが
いちばん簡単だし、わかりやすいし、無駄も無い。
初期化順が問題になることも無いでしょ。

0268259

2007/03/04(日) 07:17:53

>>267
> そんな本質的じゃない部分を指摘してうれしい？

気を悪くされたならすみません。
Cで書いた場合のコードに、>>255と本質的な違いがあるのか？と
問いたかっただけです。
newが使えないだけではなく、クラスも使えませんよね。
>>261は全くCのコードではありません。

> 件の部分は、(ほぼ)同時に突入したら、当然複数初期化される。
単に複数回初期化されるだけでなく、メモリリークが発生しますね。

0269デフォルトの名無しさん

2007/03/04(日) 08:14:12

> メモリリークが発生しますね。
だからわざわざ(本来なら省略しても良い)deleteまで書いたんだけど？

0270デフォルトの名無しさん

2007/03/04(日) 08:17:06

まさかとは思うけど
「実行中に確保(初期化)されて、終了時でも解放されないままのもの」
という意味で「メモリリーク」という言葉を使っている、
More Effective C++すら読んでないような初心者だったら、ごめんよ。

0271デフォルトの名無しさん

2007/03/04(日) 08:20:53

>>268
>>261はいろいろ省略してるのだけど、InterlockedCompareExchangePointerを使えといってるのだと思うよ。

＞Cで書いた場合のコードに、>>255と本質的な違いがあるのか？と
＞問いたかっただけです。

どちらも遅延初期化で本質的な違いはなさそうだけど、
>>261はダブルチェックロッキングが正しく出来ているが>>255には穴がある。

0272259

2007/03/04(日) 08:27:12

>>269
理解しましたm(_ _)m
他スレッドのInterlockedExchangePointer()によって値が変えられていたら
deleteするという意味なのですね。

Cで書くと
static CRITICAL_SECTION *p = 0;
if (!p) {
　CRITICAL_SECTION *q = malloc(CRITICAL_SECTION);
　InitializeCriticalSection(q);
　InterlockedExchangePointer(&p, q);
　if (p != q)
　　free(q);
}
でしょうか。

0273259

2007/03/04(日) 08:30:03

んが。
malloc(sizeof(CRITICAL_SECTION));
ですね。

それと。InterlockedExchangePointer()ではなく、
InterlockedCompareExchangePointer()を使わなければならないのですか。

むずかしい...。

0274259

2007/03/04(日) 08:32:30

>>271
>>255のコードの穴というのは、>>259に書いたのとは別のものでしょうか。

0275デフォルトの名無しさん

2007/03/04(日) 09:21:12

あーそうか、ほんとごめん。
確かに>>271の通り、CompareExchangeの方のこと(つまり>>258が俺の凡ミス)。
俺が重要な部分を間違えていたのに、意図を理解してくれる人がいてくれて助かった。
他の人も含め、ごめんね。

>>259では、本質的な解決にならないと思うよ。
つまり、比較(テスト)と初期化(&代入)の間に他のスレッドに割り込まれる可能性を消すには
atomicなCASを実行するしかないって事。

0276デフォルトの名無しさん

2007/03/04(日) 09:31:57

あ、そうか、>>255を見るとInterlockedを使っているのか。
でも、InterlockedIncrementは正負と0しか判定できないんじゃなかったかな。

で、仮に
初期値を-1として
2^32個以上のスレッドが同時に初期化部に入ることは有りえないとして
>>259の修正(Inc失敗なら他のスレッドを待つ)を加えて
当然volatileにして
とすれば、正常に動くのかな。

でもそこまでするなら、やっぱりCASを使う方がまともかと。

0277259

2007/03/04(日) 09:40:12

>>276
はい。CAS方式がエレガントでまともなコードであると納得できました。
Sleep()ループで待つなんてカッコ悪いことは出来ればしたくありません...。
有難うございます。

0278デフォルトの名無しさん

2007/03/04(日) 09:45:22

ここまでやれば大丈夫だと思うけど。
if (!initialized)
if(InterlockedIncrement(&lock) == 1) {
　　pthread_mutex_init(&mutex, 0);
　　initialized = 1;
    メモリバリア～～
} else {
    while (!initialized) {
        Sleep(1);
        メモリバリア～～　　またはinitializedが揮発性であることが必要
    }
}
}
老婆心から言えばスレッド生成前までに作っておいたほうがよいと思う。
スレッド生成後の初期化なんてバグの元。
PTHREAD_MUTEX_INITIALIZERマクロが何をやってるか調べてみたら何かヒントがあるかもしれないね。
javaで有名になったダブルチェックロッキングの話はまだ半分くらいしか理解できてないしなorz

0279デフォルトの名無しさん

2007/03/04(日) 09:47:50

InterlockedIncrementはWin95以前だと正負と0の判定しかできないので>>255のようには使えないよね。

あと厳密に言えばの話だけど
このスレの上のvolatile関連の議論からするとinitialized=1;の変更がキャッシュのせいで
他のスレッドに伝わらないかもしれない(規格的には)ので>>255のinitializedにはlock命令が必要だけど
lock命令を追加しようとすると結局>>261みたいになってしまうんじゃないかな。

別に言わなくてもわかるだろうけど
>>255は volatile static int lock = 0;
>>272は
volatile static CRITICAL_SECTION *p = NULL;
if (p != q) { DeleteCriticalSection(q); free(q); }

0280デフォルトの名無しさん

2007/03/04(日) 09:49:12

> PTHREAD_MUTEX_INITIALIZERマクロが何をやってるか
これはさすがに定数値を{}なりで囲んでるだけだと思うけど。
Cでも使えるんだし。

0281259

2007/03/04(日) 09:52:14

PTHREAD_MUTEX_INITIALIZERは単に{ 0 }
とかだと思います。

>>279
うわ。赤面しまくりです...。

ぶっちゃけUnixベースのライブラリをちょろっといじくってWin32に
移植しようと思っただけなのですが、こんなワナが待っていたとは
思ってもいませんでした。

0282デフォルトの名無しさん

2007/03/04(日) 10:24:41

下の例の場合変数iにvolatileは必要かどうか質問です。
lock, unlockがメモリバリアだから必要ないという認識なのですがつけている例も見ます。
>>261だとlockせずに読んでる箇所もあるので必要なのかもしれませんが、
この辺の基準ってどうされていますか？

int i;

thread_function() {
   mutex.lock()
   i = i + 1;
   mutex.unlock()
}

0283デフォルトの名無しさん

2007/03/04(日) 10:32:03

だれか
.NET Frameworkのメモリモデルとかに詳しい人おらんかね？

0284デフォルトの名無しさん

2007/03/04(日) 10:42:25

>>282
付けといた方がいいんじゃない？mutexのメモリバリアでcpuキャッシュの同期は取れても
スタックやレジスタに積まれたままだったら意味ないしね。

0285デフォルトの名無しさん

2007/03/04(日) 11:17:03

>>283
設計上はウィークメモリオーダリングということなので、OoOあり～の、コヒーレンシキャッシュは信用できね～のです。
今のところ実装上はx86系のWindows上ではストロングメモリオーダリングのみ。
Itaniumは構成によってウィークメモリオーダリングもある得るそうです。

0286デフォルトの名無しさん

2007/03/04(日) 11:51:52

ところが、CLR2.0では書き込みオーダは保証されてて、
今後もそうだと約束されてるらしい。

それはおいといて、よく理解できてないのが、
書き込みスレッドでメモリバリアを実行した場合、
読み込み前のメモリバリアは必要なのかどうか。

あるメモリ領域に書き込みしてメモリバリア実行、その後完了フラグセット。
別スレッドで完了フラグを確認してからメモリ領域を読み込みってときに、
完了フラグ確認後にメモリバリアは必要なのかどうか。
なんとなく読み込み順が保証されないから必要な気もするんだが、
.NETのメモリバリア命令はフルメモリバリアだから不要？ってのも見た。
.NETのメモリバリアは別プロセッサの読み込みキャッシュもクリアして
かつJITの最適化とかで先読みとかがおこらないなら大丈夫なんだと思うんだけど
この方面素人なのでいまいちよく分からない。

0287デフォルトの名無しさん

2007/03/04(日) 11:53:25

メモリバリアの説明には、このプロセッサ上でキャッシュをフラッシュするとかって説明になってんだよね…

0288デフォルトの名無しさん

2007/03/04(日) 13:04:32

Itaniumだと、そもそもout of orderしないですな。
命令の並べ替えや並列化はすべてコンパイラの仕事だ。

0289デフォルトの名無しさん

2007/03/04(日) 13:11:11

だからこそ　その辺の事情は本来プログラムで意識したくないよな・・・

DCLの欠点なんて最たるものだし

0290デフォルトの名無しさん

2007/03/04(日) 17:17:43

>>282
メモリバリアだから必要ないという認識では、ちょっと違うね。
関数呼び出しをまたいでグローバル変数をキャッシュできないから
volatileが必要ないというのが本質。
変数をレジスタ等にキャッシュしていないからこそ、メモリバリアが有効になる。

仮にlockやunlockをインライン展開できるようなコードで実装できたとすると
while() { lock(); i = i + 1; unlock(); } はvolatileが無いと危険かもしれない。

0291デフォルトの名無しさん

2007/03/04(日) 19:41:48

>>290
それは本質じゃなく単なる実装の話だと思います。
たとえばmsvc++などは次の理由からそういう実装になっています。
現在のx86系WindowsはOoOはやっててもアプリからは見えないハード的な仕掛けになっていますし、
コヒーレントキャッシュもある前提なのでキャッシュによる不整合もありません。
x86はレジスタの数が少ないので関数呼び出しのタイミングで変数をメモリ上に書き出します。

たとえばpthreadのmutexではvolatileは不要とドキュメントにあります。
すべてのコンパイラがそうなってるかどうかは分かりませんが、少なくともスレッド系のライブラリと一体で
提供されている環境ではサポートされているはずです。

0292デフォルトの名無しさん

2007/03/04(日) 20:23:08

>>291
インライン展開できない関数を呼ぶ前は、x86であろうと無かろうと
非ローカル変数をキャッシュできないよ。
レジスタの数が問題なのではなく、非ローカルな変数は呼び出した先で
更新される可能性があるから。

0293デフォルトの名無しさん

2007/03/04(日) 21:03:48

あと、ローカル変数でも、アドレスを取って他の関数に渡している場合に
その前と後で変数の中身が変更される可能性は、コンパイラも考慮しているはず。
だから例えば>>255のlockや>>272のpにはvolatile不要なはず。
もちろん、>>255のinitializedには必要だけどね。

で、pthread_mutex_tも、アドレスを取って渡すのだからvolatile不要、
という考え方でも充分かもしれない。

ただし、アドレスを取って呼び出した関数から戻った後に
変数の中身が他のスレッドによって変更される可能性は考慮されないので
レジスタにキャッシュされるかもしれない。
それが問題になる可能性がある(コードで中身を参照している)ならば
volatileが必要になるね。

0294デフォルトの名無しさん

2007/03/04(日) 21:29:48

>>292
確かにそこは例えが悪かったので取り消します。
(PGOのような広域のインライン展開のことを考えていたのですが論旨に合わないようです）
言いたかったのは同期関数の呼び出しのタイミングで
偶然レジスタとメモリの同期が取られているという話ではなく、
メモリバリア実現の属性のひとつとして関数の呼び出し時にレジスタとメモリの同期が
とられるという仕組みが利用されてるということです。
だから、レジスタとメモリの同期以外にＣＰＵキャッシュ間の同期やOoOの調整が必要ならば
その処理が同期関数に含まれていなければならないと考えているわけです。

0295デフォルトの名無しさん

2007/03/05(月) 18:53:41

　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼
　　　　　／　　─　　 ─＼
　　　　／　　（●）　（●）＼馬鹿ばっか
　　　　|　　　　（__人__）　　 |
　　　＼　　　　｀ ⌒´　　／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､.
　　ヽ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

0296デフォルトの名無しさん

2007/03/05(月) 22:57:17

volatile旋風スゴス

0297デフォルトの名無しさん

2007/03/10(土) 22:35:07

質問です。

while ( count > 1 ){
　pthread_cond_wait( &cond_t, &mutex );
}
この場合、条件変数と呼ばれるものはcountですか？
それともcond_tになるのでしょうか？
また、countのチェックにifは使ってはならない。と言われたのですが、
なぜだか解りません。
上記の部分と、
while (1){
　if( count > 1 ) pthread_cond_wait(ry);
}
は同じだと思うのですが・・・
よろしくお願いします

0298デフォルトの名無しさん

2007/03/10(土) 22:51:41

>>297

while (1)
{
if( ! (count > 1) ) break;
pthread_cond_wait(ry);
}
と同じだと思う。

0299デフォルトの名無しさん

2007/03/10(土) 23:04:21

>>298
そうでした。すんません

0300デフォルトの名無しさん

2007/03/10(土) 23:33:31

> 条件変数と呼ばれるものはcountですか？それともcond_tになるのでしょうか？
条件変数はcond_t。!(count>1)は述語。

> countのチェックにifは使ってはならない。と言われたのですが、
言った本人に聞けばいいと思う。いけないってことは無いと思う。
pthread_mutex_lock(&mutex);
while (!pred(ry))
　pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);
というのが定型パターンの予感はするんで、
その人にとって奇怪なコーディングするなという意味かもしれん。

0301デフォルトの名無しさん

2007/03/11(日) 08:33:14

ありがとうございます。
countは述語っていうのですか。知りませんでした。
>ifでんでん
後でもう一度聞いてみます。

0302デフォルトの名無しさん

2007/03/11(日) 11:25:05

でんでんってなんだ。云々（うんぬん）と言いたいのか、わざとボケてるのかどっちだ。

0303デフォルトの名無しさん

2007/03/11(日) 12:35:43

>>302
単なる2chのジャーゴンだから気にするな

0304デフォルトの名無しさん

2007/03/11(日) 14:17:43

countが述語なんじゃなくて
"count>1"が述語
countは単なる変数

0305301

2007/03/11(日) 15:38:51

>>304
"count>1"で、述語。ですか。解りました。
ありがとうございます。

>>でんでん
"うんぬん"で"云々"ですか。初めて知りました
ゆとり年代より一つ上なはずなんだけどゆとりでごめんなさい

0306300

2007/03/11(日) 15:43:08

ごめん。!(count>1)でなく、count>1だった。
301に幸あらんことを。

0307デフォルトの名無しさん

2007/03/11(日) 15:43:39

俺がかつて１日だけ流行らそうとしてばら撒いてたでんでんが意外な影響を。

0308デフォルトの名無しさん

2007/03/11(日) 16:04:43

「云々」を「でんでん」ってことは
「云」を「でん」と読んでるって事だよな。

俺、そもそも「云」という漢字、単独でどう読むか知らないのだが。

0309デフォルトの名無しさん

2007/03/11(日) 16:29:44

>>308
「ウン」でしょ。

0310デフォルトの名無しさん

2007/03/11(日) 16:37:38

伝が“でん”だからなあ

0311デフォルトの名無しさん

2007/03/11(日) 20:45:06

雲が「うん」と読まれることには頓着しないらしい。

0312デフォルトの名無しさん

2007/03/11(日) 22:22:20

ﾜﾝﾀﾝ
雲呑

0313デフォルトの名無しさん

2007/03/12(月) 00:36:16

うーんぬんむーしむし、かーたつむりー

0314デフォルトの名無しさん

2007/03/16(金) 09:25:59

　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼
　　　　　／　　─　　 ─＼
　　　　／　　（●）　（●）＼　　「ﾃﾗﾜﾛｽｗｗｗｗｗｗｗうぇうぇｗｗｗｗ」・・・・と
　　　　|　　　　（__人__）　　 |　＿＿＿＿＿＿＿_
　　　＼　　　　｀ ⌒´ 　 ,／　.| |　　　　　　　　　　|
　　　　ノ　　　　　　　　　　　＼　| |　　　　　　　　　　|
　／´ 　　　　　　　　　ｶﾀ.　　 | |　　　　　　　　　　|
　|　　　　ｌ　　　　　　　ｶﾀ　| |　　　　　　　　　　|
　ヽ　　　 -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__|
　　ヽ＿＿＿＿,ノγ⌒ヽ)ニニ-￣　　　| |　　|　　　　　＿＿＿_

0315デフォルトの名無しさん

2007/03/20(火) 00:12:35

ごめん書籍いいでしょっていわれてるけれど
マルチスレッドの勉強する本をおしえてほしいの

0316デフォルトの名無しさん

2007/03/20(火) 00:32:02

マルチスレッドについて本で得られるものは1%もない。
といっては見もふたもないので、もう少し具体的にマルチスレッドで何をしたいの？

OSは？マルチスレッドアプリ？APIがしりたい？それともカーネルの実装(はないよな)？

0317デフォルトの名無しさん

2007/03/20(火) 15:54:59

Unix 方面の人は「実践マルチスレッドプログラミング」
Win32の人は「Win32マルチスレッドプログラミング」

当り前のことが当たり前に書かれてるだけで、
別にいいも悪いもないけど。

このあたりに出てくるような概念、問題、手法については常識として理解した上で、
新しい手法やOS/CPU/言語毎のメモリモデルなどについての知識を深めると、
volatile 論議とかで無駄に遊べる。

0318デフォルトの名無しさん

2007/03/20(火) 23:15:04

>>315
Java使いなら↓は超オススメ。
http://www.amazon.co.jp/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601
邦訳版もあるよ。

0319デフォルトの名無しさん

2007/03/21(水) 00:27:18

>>317
素朴な疑問

> Unix 方面の人は「実践マルチスレッドプログラミング」
> Win32の人は「Win32マルチスレッドプログラミング」

この辺を読めば volatile 最強って言い切れるようになるんですか？

0320デフォルトの名無しさん

2007/03/21(水) 03:30:37

317をもう一度よく読んだほうがいいんじゃない？

0321デフォルトの名無しさん

2007/03/21(水) 04:34:08

自作自演の可能性

0322デフォルトの名無しさん

2007/03/21(水) 13:51:09

volatile厨を論破するのはそんなに簡単じゃないよ。

0323デフォルトの名無しさん

2007/03/21(水) 15:55:04

NG登録するだけだし

0324デフォルトの名無しさん

2007/03/24(土) 10:03:31

Win32の本ってオライリーのやつのことでいいの？

0325デフォルトの名無しさん

2007/03/24(土) 15:56:09

>>315
並行プログラミングの原理―プロセス間通信と同期への概念的アプローチ (単行本)

0326デフォルトの名無しさん

2007/03/27(火) 14:50:58

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　volatile厨を論破するのはそんなに簡単じゃないよ。
　　　　|　　　　　|r┬-|　　　　|　　
　　　　＼　　　　 `ー'´　　／
　　　　　　＿＿＿
　　　　　　　／　　　　＼
ｸｽｸｽｯ　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼
　　　　|　　（__人__）　　　u. 　 |
　　　＼　u.｀ ⌒´　　　　　／
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼！？？
　　　　　／　　u　　ノ　　＼　　ｸｽｸｽｯ
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／

0327デフォルトの名無しさん

2007/03/27(火) 22:33:12

Javaのsynchronizedとwaitとnotifyに関する質問なんだが

http://www.javaworld.jp/technology_and_programming/-/10941-5.html
ここの

class Buffer {
private int value;
private boolean isEmpty = true;
public synchronized void putValue(int v) {
while (!isEmpty) {
try {
wait();
} catch (InterruptedException e) { }
}
notifyAll();
isEmpty = false;
value = v;
}
public synchronized int getValue() {
while (isEmpty) {
try {
wait();
} catch (InterruptedException e) { }
}
notifyAll();
isEmpty = true;
return value;
}
}
これがどうして動くのか分からん。
あるスレッドがgetValueに入ってる間は、ほかのスレッドは
getValueにもputValueにも入れないんじゃないのか

0328デフォルトの名無しさん

2007/03/27(火) 22:34:13

すまんソースコードが見づらくなってしまった。
リンク先を見てくれ。

0329デフォルトの名無しさん

2007/03/27(火) 22:52:21

>>327
前のページで説明されてる。

0330デフォルトの名無しさん

2007/03/27(火) 22:53:08

ttp://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/api/java/lang/Object.html#wait()

の二段落目を理解できない無能？

0331デフォルトの名無しさん

2007/03/27(火) 23:05:42

すまんかった。
とんくす

0332デフォルトの名無しさん

2007/03/28(水) 08:53:09

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　の二段落目を理解できない無能？
　　　　|　　　　　|r┬-|　　　　|　　
　　　　＼　　　　 `ー'´　　／
　　　　　　＿＿＿
　　　　　　　／　　　　＼
ｸｽｸｽｯ　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼
　　　　|　　（__人__）　　　u. 　 |
　　　＼　u.｀ ⌒´　　　　　／
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼！？？
　　　　　／　　u　　ノ　　＼　　ｸｽｸｽｯ
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／

0333デフォルトの名無しさん

2007/04/01(日) 13:51:44

LAN 内の複数のファイルサーバーから
(巨大な) ファイルを一括してダウンロードするプログラムを作成していますが、
おそらくネットワーク通信がボトルネックになるので、
サーバーごとにスレッドを作成してマルチスレッド化しても
高速化にならないですよね？

0334デフォルトの名無しさん

2007/04/01(日) 16:37:27

小さいファイルを大量に、だったら考えられなくもないけどね・・・

0335デフォルトの名無しさん

2007/04/02(月) 03:32:43

>>333
それぞれのサーバーのレスポンスが回線速度より相当遅ければ
早くなる可能性はあるんじゃね？

LAN内だとレアケースかもしれんけどWANならそれなりに効果はある。
効果があるかどうかは1サーバーからのダウンロードだけで帯域を
使い切っているか計測してみればいい。

0336デフォルトの名無しさん

2007/04/02(月) 10:30:45

>>333
LANだったら、下手に同時に別のサーバにアクセスすると却って遅くなるかもしれないね。

0337デフォルトの名無しさん

2007/04/02(月) 16:52:23

　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼
　　　　　／　　─　　 ─＼
　　　　／　　（●）　（●）＼　　　＜春だなぁ・・・と
　　　　|　　　　（__人__）　　 |　＿＿＿＿＿＿＿_
　　　＼　　　　｀ ⌒´ 　 ,／　.| |　　　　　　　　　　|
　　　　ノ　　　　　　　　　　　＼　| |　　　　　　　　　　|
　／´ 　　　　　　　　　　　　　 | |　　　　　　　　　　|
　|　　　　ｌ　　　ｶﾀｶﾀ　　　　 | |　　　　　　　　　　|
　ヽ　　　 -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__|
　　ヽ＿＿＿＿,ノγ⌒ヽ)ニニ-￣　　　| |　　|　　　　　＿＿＿_

0338デフォルトの名無しさん

2007/04/08(日) 23:05:26

で、このスレの品質は>>295が結論でおｋ？

0339デフォルトの名無しさん

2007/04/09(月) 20:11:29

自分で考えないから>>295とか書かれちゃうんだよ

0340デフォルトの名無しさん

2007/04/10(火) 09:03:48

　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼
　　　　　／　　─　　 ─＼
　　　　／　　（●）　（●）＼　　　＜俺も何も考えずにそれ貼ったんだけどね・・・
　　　　|　　　　（__人__）　　 |　＿＿＿＿＿＿＿_
　　　＼　　　　｀ ⌒´ 　 ,／　.| |　　　　　　　　　　|
　　　　ノ　　　　　　　　　　　＼　| |　　　　　　　　　　|
　／´ 　　　　　　　　　　　　　 | |　　　　　　　　　　|
　|　　　　ｌ　　　ｶﾀｶﾀ　　　　 | |　　　　　　　　　　|
　ヽ　　　 -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__|
　　ヽ＿＿＿＿,ノγ⌒ヽ)ニニ-￣　　　| |　　|　　　　　＿＿＿_

0341デフォルトの名無しさん

2007/04/10(火) 20:04:29

内容が稚拙なのは確かだな

0342デフォルトの名無しさん

2007/04/10(火) 20:47:37

やっぱ玄人は
「マルチスレッドロジックにマルチスレッドロジックが重なるアミダのトグロｗで超絶難しい」
だよなｗ

0343デフォルトの名無しさん

2007/04/10(火) 21:50:29

一度ハマるとそれを避けるようになるよ
気がついたらシングルスレッドに

0344デフォルトの名無しさん

2007/04/10(火) 22:22:45

と似非コンサルがさも大発見をしたかのようにおっしゃりましたとさ

0345デフォルトの名無しさん

2007/04/11(水) 00:12:09

確かに一番の解決策は
「マルチスレッドを使わない事」かも

コンパイラなりインタプリタなりが、自動的にマルチスレッド化してくれるのが理想だけど
まぁ無理だろうね

0346デフォルトの名無しさん

2007/04/11(水) 00:26:05

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　と似非コンサルがさも大発見をしたかのようにおっしゃりましたとさ
　　　　|　　　　　|r┬-|　　　　|　　
　　　　＼　　　　 `ー'´　　／
　　　　　　＿＿＿
　　　　　　　／　　　　＼
ｸｽｸｽｯ　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼
　　　　|　　（__人__）　　　u. 　 |
　　　＼　u.｀ ⌒´　　　　　／
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼！？？
　　　　　／　　u　　ノ　　＼　　ｸｽｸｽｯ
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／

0347デフォルトの名無しさん

2007/04/11(水) 08:11:00

必死だなぁ

0348デフォルトの名無しさん

2007/04/11(水) 09:11:05

>>345
最近は自動的にマルチスレッド化してくれるコンパイラもあるじゃん。Intelとか。
CoreMicroFusionが利かなくなるとか、ほとんど効果が無いという問題はあるけど。

0349デフォルトの名無しさん

2007/04/11(水) 09:20:30

あれは複数パイプラインのスケジューリングの延長線上に過ぎないだろう

0350デフォルトの名無しさん

2007/04/11(水) 11:20:11

「アミダのトグロ」で釣れまくってるな。

釣れたのは全部、似非技術コンサルみたいだけどｗ

0351デフォルトの名無しさん

2007/04/11(水) 12:20:42

openmpのような自動的なのって流行るのかねぇ？
それほどのヘビーロードな用途があんまり見えん
今の用途がつまんないWebアプリに偏ってるというのもあるけど

0352デフォルトの名無しさん

2007/04/11(水) 12:32:51

流行とか関係なく必要な場面で必要な人が使うだけ。
科学技術計算や並列処理とは無縁な
似非業務コンサルには一生関係。

0353デフォルトの名無しさん

2007/04/11(水) 12:34:31

流行とか関係なく必要な場面で必要な人が使うだけ。
科学技術計算や並列処理とは無縁な
似非業務コンサルには一生関係なっしんぐ。

似非コンサルが気付かないうちに
一般向けにマルチコア対応コンパイラーが普及するだろ

0354デフォルトの名無しさん

2007/04/11(水) 13:01:42

>>351
流行ってないじゃん

0355デフォルトの名無しさん

2007/04/12(木) 03:23:28

技術計算で本格的に使うならOpenMPよりMPI

0356デフォルトの名無しさん

2007/04/12(木) 08:16:39

いつも思うんだけどさぁ、
そこで一行tipsみたいなハッタリしか書かない奴って
議論上どう扱ったらいいのさ？

ググルくん？

0357デフォルトの名無しさん

2007/04/12(木) 08:22:59

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　一行tipsみたいなハッタリしか書かない奴って議論上どう扱ったらいいのさ？
　　　　|　　　　　|r┬-|　　　　|　　
　　　　＼　　　　 `ー'´　　／
　　　　　　＿＿＿
　　　　　　　／　　　　＼
ｸｽｸｽｯ　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼
　　　　|　　（__人__）　　　u. 　 |
　　　＼　u.｀ ⌒´　　　　　／
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼！？？
　　　　　／　　u　　ノ　　＼　　ｸｽｸｽｯ
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／

0358デフォルトの名無しさん

2007/04/12(木) 08:57:53

議論とか一行tipsってなんだ？
質問したのに回答をもらえなかったやつが粘着してんのかｗ

0359デフォルトの名無しさん

2007/04/12(木) 09:03:48

変なAA書きと変な文句言いが
24時間体制で常駐している事は理解できた

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　議論とか一行tipsってなんだ？質問したのに回答をもらえなかったやつが粘着してんのかｗ
　　　　|　　　　　|r┬-|　　　　|　　
　　　　＼　　　　 `ー'´　　／
　　　　　　＿＿＿
　　　　　　　／　　　　＼
ﾁﾈｸｽﾞｯ　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼
　　　　|　　（__人__）　　　u. 　 |
　　　＼　u.｀ ⌒´　　　　　／
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼！？？
　　　　　／　　u　　ノ　　＼　　ﾋｯｺﾒﾊﾞｰｶ
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／

0360デフォルトの名無しさん

2007/04/12(木) 10:45:01

オブジェクト指向って使わんの？

0361デフォルトの名無しさん

2007/04/12(木) 12:04:24

ライブラリとかで配布する以外なら使う必要ないとかあった。ものは作れればい院です

0362デフォルトの名無しさん

2007/04/12(木) 12:11:36

俺もそう思う

ものが出来ればやり方なんてなんでもいいと思う

業務で使うなら色々制限はあるだろうけども

0363デフォルトの名無しさん

2007/04/12(木) 19:15:12

OpenMPはそもそもたいしてスケールしない上に、
ターゲットであるところの多重度が低い用途でさえも現状
MPI に性能で負けてるってのが定説なんじゃないの？
コード書くのは楽だけど。

インテルあたりの実装が変わったかなにかして進展でもあったのか？

0364デフォルトの名無しさん

2007/04/12(木) 19:52:46

技術計算で本格的に使うならOpenMPよりMPI

0365デフォルトの名無しさん

2007/04/12(木) 21:11:26

Visual C で信号処理シミュレーションのプログラムを書いています。
一部、処理の高速化のためインラインアセンブラでＳＳＥ２の命令を
使おうとしています。
ここで疑問が生じて悩んでいます。それは次のとおりです。

WINDOWS XPのマルチスレッドでスレッドが切り替わった瞬間は、
ＣＰＵのＸＭＭレジスタの値はスタックにＯＳのカーネルが退避して
くれるのか？ということです。
それとも、スレッド切り替えを検知して、ＸＭＭレジスタの値を
退避させるコードを自分で書く必要があるのでしょうか。

環境は次のとおりです。
OS：WINDOWS XP
開発環境:Visual C++ .net 2003

0366デフォルトの名無しさん

2007/04/12(木) 21:33:26

OSがそのCPUに対応してればユーザプロセス側で考慮する必要はないやろ。

XP無印は2002年だっけ、その頃もうXMMレジスタがあったと思うけど。

0367デフォルトの名無しさん

2007/04/12(木) 21:41:19

>それとも、スレッド切り替えを検知して、ＸＭＭレジスタの値を
>退避させるコードを自分で書く必要があるのでしょうか。

こういうコードは書こうとしても書けないと思います。

0368365

2007/04/12(木) 22:31:48

ありがとうございます>>366 >>367

スレッド切り替え時のＸＭＭレジスタ管理は、
ＯＳ側でやってもらえるつもりで作ってみます。

0369デフォルトの名無しさん

2007/04/12(木) 23:55:36

>>365
やっとメモが出てきた。
ＳＳＥのＳＩＭＤ命令を使うためにはCR4のOSFXSRビットが立っている必要があってこのビットはOSが立てる。
ＯＳがSIMDをサポートしてない場合はこのビットが立っていないので、そもそもＳＩＭＤ命令が使えない。
CR4の読み書きは保護レベル０でないと出来ないので、アプリから実際に命令が使えるどうかの
判定は実行してみてＧＰ（CPU例外）を捕まえるしかない。
ただしＣＰＵにＳＩＭＤの能力が潜在的にあるかどうかはＣＰＵＩＤ命令でわかる。

0370デフォルトの名無しさん

2007/04/13(金) 00:48:01

>>365
趣味でやるなら止めないが、業務でやるならiccを使う方が(早|速)いかもよ。

0371デフォルトの名無しさん

2007/04/13(金) 01:27:36

>>365
Windows だったら、IsProcessorFeaturePresent() で調べてOKならOSが
サポートしているということ。

0372デフォルトの名無しさん

2007/04/13(金) 22:07:03

あるオブジェクトに対し、読み込みスレッドが多数、書き込みスレッドがひとつだけあります。

読み込みスレッド同士は排他したくないんですが、書き込みスレッドがアクセス中は
読み込みスレッドと排他したいのです。

こういう場合どういう排他制御が定石でしょうか？　Win32APIで
クリティカルセクションでオブジェクトを囲ってしまうと、読み込み書き込み
の同時アクセスは防げますが、読み込み同士でも排他しあって具合が
よくありません。

0373デフォルトの名無しさん

2007/04/13(金) 22:27:57

スレッドで制御するよりSQL標準で
SELECTは共有ロック、UPDATE、INSERT、DELETEは排他じゃなかたかな

0374デフォルトの名無しさん

2007/04/13(金) 22:33:01

>>372
http://en.wikipedia.org/wiki/Readers-writer_lock

0375デフォルトの名無しさん

2007/04/13(金) 23:00:41

>>372
Advanced Windowsにシングルライタ/マルチリーダガードの例があるよ。
下手に作ると単純にクリティカルセクションで囲むよりも遅くなると思う。

0376デフォルトの名無しさん

2007/04/13(金) 23:00:59

>>372
読み込みスレッドは TryEnterCriticalSection で
ブロックさせずにクリティカルセクションの所有権を取得。

書き込みスレッドは EnterCriticalSection で
普通に排他させればいけると思う。

（ただしTryEnterCriticalSection はNT系OSのみのサポート）

0377372

2007/04/13(金) 23:02:12

名前のヒントをいただいたので、
Readers　writer　lock
でググってみました。

Win32APIだと既成の同期オブジェクト一個をそのまま使う
というのでは済みそうに無いですね…。

ありがとうございました。

0378372

2007/04/13(金) 23:10:23

>>376
読み込みスレッドにて、TryEnterCriticalSectionで所有権の
取得に失敗して戻ってきた時、所有してるのが他の読み込みスレッド
か書き込みスレッドなのかはどう判断するんでしょうか？

>>375
その本持ってないもので…

0379372

2007/04/13(金) 23:21:23

シングルライタ/マルチリーダガード（SWMRG）

http://pck338-48.feld.cvut.cz/cd_win/BUCKET/SWMRG.C
これでしょうか？　うーむ＾＾；

0380デフォルトの名無しさん

2007/04/13(金) 23:33:09

>>378
たしかに376のやりかただと
読み込みスレッドが所有権を取得しているときは
書き込みスレッドはブロックできるが、
書き込みスレッドが所有権を取得しているときに
読み込みスレッドがブロックできないので、
以下のように書き込みスレッドの所有権を示すフラグを用いる。

１．書き込みスレッドが EnterCriticalSectionを呼ぶ直前にフラグ立てる。
２．読み込みスレッドがそのフラグを見て、フラグがたっていれば
EnterCriticalSection、たってなければTryEnterCriticalSectionを呼ぶ。
３．書き込みスレッドで LeaveCriticalSection を呼んだ直後にフラグをおとす。

0381デフォルトの名無しさん

2007/04/14(土) 01:26:57

だめだめだろ

0382デフォルトの名無しさん

2007/04/14(土) 01:31:20

読み取りスレッド１がロック開始
読み取りスレッド２がTry～で失敗、でも読み取りなので続行
読み取りスレッド１が処理完了、ロック開放
書き込みスレッドがロック開始
読み取り操作とバッティング

0383デフォルトの名無しさん

2007/04/14(土) 02:00:24

ReadWriteLockっていうやつのことか

0384デフォルトの名無しさん

2007/04/14(土) 05:53:59

ReadWriteLockはいったんMonitorもどきを作れば、
ネット上に転がっているJava用のソースが流用できるようになる。
lock/unlock/nitifyAｌｌが実装できれば十分。

0385デフォルトの名無しさん

2007/04/14(土) 07:11:59

この辺参考にすればOK
http://www.google.co.jp/search?q=apr+rwlock+win32&lr=lang_ja

0386デフォルトの名無しさん

2007/04/14(土) 09:26:22

下手に使うと余計遅くなるから注意。

0387デフォルトの名無しさん

2007/04/14(土) 09:38:12

vistaからReadWriteLockのAPIが新設されたような…

0388デフォルトの名無しさん

2007/04/14(土) 09:46:05

あったけど Requires Windows Vista. なんだよなあ
ttp://msdn2.microsoft.com/en-us/library/aa904937.aspx

0389 ◆0uxK91AxII

2007/04/14(土) 17:13:44

>>372
＞具合がよくありません。
具合は良い。

0390デフォルトの名無しさん

2007/04/15(日) 04:28:24

ttp://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.boost.read_write_mutex.html

0391デフォルトの名無しさん

2007/04/21(土) 00:46:46

Compare and swapとかwait-free関連の参考書教えてください。
古くさいAPIの使いかた載った本は一応全部あります。

0392デフォルトの名無しさん

2007/04/21(土) 00:52:18

まずは、その古臭いAPIの載った本の一覧を書いてもらおうか。

0393デフォルトの名無しさん

2007/04/21(土) 01:53:20

>>387-388
Vistaってpthred風のCondition Variablesなんかも追加されてるのか。
なにげにスレッド関連のAPI拡張多いな。

0394デフォルトの名無しさん

2007/04/21(土) 12:30:49

「一回だけ初期化」用の仕組みも追加されてる
なにげにうれしい

つかXPまでとvista以降では作り方が変わってしまわないかな・・

最近気づいたんだが、mutexの獲得が要求順じゃなくなってるのな
server 2003から変わったらしい

0395デフォルトの名無しさん

2007/04/21(土) 14:33:45

「一回だけ初期化」ってどういうの？

0396デフォルトの名無しさん

2007/04/21(土) 15:01:16

シングルトンのインスタンス生成を確実に一度だけ行うとかじゃない？
pthread_onceみたいな。

0397デフォルトの名無しさん

2007/04/21(土) 19:30:06

なるほど、あったら便利かも。

0398デフォルトの名無しさん

2007/04/21(土) 20:52:29

どうせマイクロソフトの実装なんぞあてになんねーんじゃねぇの？

0399デフォルトの名無しさん

2007/04/21(土) 22:11:58

どっちかっていうと、POSIX準拠のために追加したんじゃないかね。
VistaのUnix互換機能はかなり強化されてるみたいだし。

0400デフォルトの名無しさん

2007/04/21(土) 23:12:43

Windows捨てろよ

0401デフォルトの名無しさん

2007/04/22(日) 00:12:46

API だけ UNIX 並みになっても…

0402デフォルトの名無しさん

2007/04/22(日) 01:08:26

Windowsには全く必要ない機能でも、移植性のためにわざわざ
用意してるものもあるよ。ファイバーとか。

0403デフォルトの名無しさん

2007/04/22(日) 01:59:07

ファイバー全く必要ない機能なのかよ。

0404デフォルトの名無しさん

2007/04/22(日) 02:28:37

マイクロスレッディングのようなことでもやらんかぎり・・・

0405デフォルトの名無しさん

2007/04/22(日) 17:44:54

Linuxカーネル2.4系でスレッドを特定のCPU上で実行させる(CPUを選択できる)
手段はありますか？

0406デフォルトの名無しさん

2007/04/22(日) 18:24:37

sched_[gs]etaffinity()でできない?

0407デフォルトの名無しさん

2007/04/22(日) 18:39:15

横レスだけど、外から affinity を変更するコマンドって無いの?

0408デフォルトの名無しさん

2007/04/22(日) 18:41:16

>>407
pidさえ判ればいいんだから、外部プロセスから幾らでもできるっしょ。
#勿論、権限があるとして。

0409デフォルトの名無しさん

2007/04/22(日) 18:47:30

まぁ、そうなんだけどね。ｻﾝｸｽ。

0410デフォルトの名無しさん

2007/04/22(日) 22:01:36

それカーネルが動いてるCPU id(普通は#0?)に対して負荷掛けることでDoS成立するね。

0411デフォルトの名無しさん

2007/04/22(日) 22:17:47

>勿論、権限があるとして。

0412デフォルトの名無しさん

2007/04/22(日) 23:04:32

>>410
1. プログラムを実行出来ている時点で…
2. カーネルってシングルスレッドで動いてるの…

どっちで突っ込んで欲しい?

ところで、Linux の CPU 割り付けって排他的には出来ないんだね。

0413デフォルトの名無しさん

2007/04/23(月) 02:08:57

show_friend.pl?id=755479('・ω・`)

0414デフォルトの名無しさん

2007/04/24(火) 10:49:19

尻穴開けて待ってるから、早く突っ込んでくれないか。
アッー！

0415デフォルトの名無しさん

2007/04/28(土) 22:52:46

>>406
それカーネル2.5..以降じゃないか？

0416デフォルトの名無しさん

2007/05/04(金) 02:41:51

緊急浮上

0417デフォルトの名無しさん

2007/05/04(金) 11:58:15

これから仕事の関係でプログラムを学ぶんですが最初はどういう事から始めたらいいですか？

0418デフォルトの名無しさん

2007/05/04(金) 12:02:59

指示出した奴に聞け

0419デフォルトの名無しさん

2007/05/04(金) 12:38:19

次の職種のピックアップ。

0420デフォルトの名無しさん

2007/05/04(金) 13:37:59

マルチスレッド１度も使ったことがないんだが、どういう場合に使うものなの？

0421デフォルトの名無しさん

2007/05/04(金) 13:39:57

>>420
sleep等使う処理の場合主スレッドでやるとビジー状態になる為
そういう場合サブスレッドに任せて使えば主スレッドは生きる

0422デフォルトの名無しさん

2007/05/04(金) 14:05:31

マルチプロセスだとメモリリークがたまにあっても
プロセスごと解放されてシステムピンチにならないけど
マルチスレッドでメモリリークあるといつまでも解消されず
致命的になるケースがあるということが分かりました
回避する方法ってリークしないように作るしかないですか？

0423デフォルトの名無しさん

2007/05/04(金) 14:11:32

>>422
そのスレッドが終了すれば解放されますが。

0424デフォルトの名無しさん

2007/05/04(金) 14:29:24

>>422
そもそもリークさせてるプログラムを作ってる事自体間違ってる

0425デフォルトの名無しさん

2007/05/04(金) 19:24:42

Apacheが同じ道をたどっているので、
apr_pool系関数 (Apache Portable Runtime)を調べてみるよろし

0426デフォルトの名無しさん

2007/05/04(金) 19:41:26

>>420
本当にマルチスレッド化をするメリットを見出せないで使っている奴は、
色々と複雑で難度が高いものが好きで、あのアミダの様な処理シーケンスの
ギミックで遊びたいか、興行的ｗなプログラマーの誇示と道楽で使うもの。

サーカスのハイレベル空中ブランコや4個以上のお手玉などと一緒。

0427デフォルトの名無しさん

2007/05/04(金) 20:36:48

似非コンサル乙

0428デフォルトの名無しさん

2007/05/04(金) 21:11:54

>>420
おれは画像処理の高速化に使ってる（要HT、マルチコア）。
シングルプロセッサ環境より確実に速くなる。

0429デフォルトの名無しさん

2007/05/04(金) 23:55:15

負荷が高く並行処理可能で、マルチコア、マルチCPUなら、確かに効果はあるな。

0430デフォルトの名無しさん

2007/05/06(日) 00:23:18

また似非コンサルが片言知識で騒いでるなｗ

0431デフォルトの名無しさん

2007/05/07(月) 23:20:42

他のプログラムでパイプラインが埋まってたら、ミスキャッシュで遅くなりまくりだろう。

0432デフォルトの名無しさん

2007/05/07(月) 23:44:40

＞他のプログラムでパイプラインが埋まってたら
ほうほう？

0433デフォルトの名無しさん

2007/05/08(火) 00:37:34

相変わらず、ワナビーに厳しいスレだなw

0434デフォルトの名無しさん

2007/05/08(火) 00:41:36

彦○呂「見て～! 思考のスパゲッティー状態や～～(間)ナマ茹でだし↓」

0435デフォルトの名無しさん

2007/05/08(火) 00:53:49

>>420
元々独立した処理が並列に複数同時に動くような状況では、
無理にシングルスレッドで組むよりもマルチスレッドの方が簡単になる。

例えばWebサーバのようなサーバアプリケーションでは、主スレッドで
クライアントからの接続を管理して、クライアントから要求が来たら
スレッドを作って処理させるのが基本。(1クライアント=1スレッド)
これで簡単にマルチクライアントのサーバが作れる。

これをシングルスレッドで同じことをやろうとすると、物凄く面倒。

0436デフォルトの名無しさん

2007/05/08(火) 01:15:09

>420
あと、どうしてもコード領域サイズが大きくとれない時、かな。
マルチスレッドにすることによって、コードサイズを節約できたりするンだよね。

組み込みとか、携帯でのテクニックだけど。

0437デフォルトの名無しさん

2007/05/08(火) 06:37:55

なんてーか、rubyでプログラミングしてるところに
「メモリブロックはこの形式で保存されるはずだから、もうちょっとヒット率を上げれば速くなる」とか
「Javaのバイトコードは～に変換されるから、XXXとYYYは同じ」とか
ユーザが立ち入っちゃいけない部分のお話をしてる風に見えるんだが

0438デフォルトの名無しさん

2007/05/08(火) 09:25:46

>>435
いまその程度でスレッド立てるなんて馬鹿のやることだよ
練習用にはいいかもしれんが

0439デフォルトの名無しさん

2007/05/08(火) 10:04:08

質問単発スレの話かと思った

0440デフォルトの名無しさん

2007/05/08(火) 10:21:27

Javaでもバイトコードとか、HotSpot/JITコンパイラのこと知らないと、
マルチスレッドプログラムではまることあるよ。

0441デフォルトの名無しさん

2007/05/08(火) 10:34:22

大抵、最初にスレッドを増やすことを覚えて、次に減らす努力を始めるね。

シングルスレッドのプログラムが書けるようになる。
↓
並行処理のためにスレッドを作ることを覚える。
↓
楽しくなってやたらとスレッドを作る。
↓
スレッド切り替えがオーバヘッドになることを覚える。
↓
非同期処理を組み合わせてスレッド数を節約する努力を始める。
↓
最終的にスレッドプールに落ち着く。

で、現代的なOSはスレッドプールのディスパッチをカーネルランドでできるAPIを持つようになる、と。
epollとかIOCPとか。
コンピューティング能力を使い切るための並列処理はまた別。

0442デフォルトの名無しさん

2007/05/08(火) 12:18:56

>>436
＞マルチスレッドにすることによって、コードサイズを節約できたりするンだよね。

理屈がよく分からないので詳しく説明してみてくれると大変ありがたい・・・
コードがシンプルになるという>>435の類の話かな。

0443デフォルトの名無しさん

2007/05/08(火) 17:29:38

>442
違う。コードはもの凄く複雑になる。その代わり、コードのサイズは節約できる。

ループで 0～10, 0～5 までの処理をマルチスレッドで行う場合、二つの関数を作り for文を置くとする。

{
for( ; i < 10 ; ) { i++; }
return;
}

{
for( ; i < 5 ; ) { i++; }
return;
}

これを、
{
for( ; i < j ; ) { i++ }
return;
}

として、j=5, と j= 10 で同じ関数をマルチスレッドで実行する。→ コードは約半分。

これを基幹ロジックに導入する。ある意味、職人技のひとつで、メンテナンス性はかなり悪い。
って話。お勧めじゃないけど、これもひとつの組み方という感じで。

0444デフォルトの名無しさん

2007/05/08(火) 18:00:17

>>443
それシングルスレッドで十分だしｗ
何か激しく勘違いしてると思う

0445デフォルトの名無しさん

2007/05/08(火) 18:17:48

>>438
マルチスレッドを使ったことが無い人に、どういうときにシングルスレッドよりも
便利なのか、一番分かりやすそうな例で簡単に説明しただけなのに、
そんなこと言われても困るんだが。

>>444
俺も443が何言ってるのか分からないな。
関数にして引数変えて呼び出すだけで済む話だよね。

0446デフォルトの名無しさん

2007/05/08(火) 21:52:54

>>441
まさに経験ですな。

0447デフォルトの名無しさん

2007/05/08(火) 22:06:12

>444
>445

いや、勘違いはしてない。
この考え方を基幹ロジックに入れるんだよ。例はわかりやすいように書いただけさ。

ま、こんな方法、知らない方が幸せだけどね。

0448デフォルトの名無しさん

2007/05/08(火) 22:33:21

>>447
その例がまったく分かりやすくない、というか誰も理解できないわけだが。
どう分かりやすいのか説明してほしい。
どんなに難しい話でもちゃんとついて行けるから、安心してください。

>>443
>として、j=5, と j= 10 で同じ関数をマルチスレッドで実行する。→ コードは約半分。
同じ関数をシングルスレッドで実行する。→やはりコードは約半分、となるでしょう？
マルチスレッド、シングルスレッドにかかわらず汎用関数化でコードを削減しているだけのように見える。

例えば漏れは昔 16bitのゲーム機用にMUAを書いたときに、一つのループに
・メールの表示
・メールの編集
・コード変換とSMTPサーバへの送信
・メールのサイズの計算
を多重化して動作モードで機能を切り替えたりしたことがあるけど、
単にそういう話ではないのですか？

0449デフォルトの名無しさん

2007/05/08(火) 22:59:23

>448
>この考え方を基幹ロジックに入れるんだよ。

と言うところかな。やはり、ポイントは。
そこが理解できてないから、汎用関数化してる、という言葉が出ちゃうんだろうな。
その文に言及しないで、例の話ばかりなのは、ついてこれてない事を自覚してみてください。

で、多重化して動作モード切替という話でも、だいたい近いので、そう考えて良いんじゃないかと思うよ。
ただ、コードサイズを小さくする事が目的、といううお話ですから。

エスパーで一文を追加すると、
それでコードサイズが小さくならんよ。って話にはならないわけ、なぜなら基幹ロジックに入れるわけだから。

0450デフォルトの名無しさん

2007/05/08(火) 23:00:41

難しいがマルチスレッドに興味ある初心者な俺にとっては有意義な話題だ

0451450

2007/05/08(火) 23:01:48

人がいるうちに聞いとこう。
マルチスレッドでの排他制御はクリティカルセクション使うことが多いと思うんだけど。
セマフォでの排他制御ってのもできるんですか？

0452デフォルトの名無しさん

2007/05/08(火) 23:18:42

synchronized unko setunko(unko){s=unko};
synchronized unko getsemlock() {if s>0 s-=1 return おk else nullpo or wait};
synchronized unko releasesemlock() {s+=1 notifyforme};
とほぼ一緒じゃないの?

0453デフォルトの名無しさん

2007/05/08(火) 23:21:42

できるにきまってるだろ。

0454デフォルトの名無しさん

2007/05/08(火) 23:22:50

>>449
基幹ロジックってなによ？
マルチスレッドにすることによってコードサイズを小さくできるってのを
具体的に示してくれればいいだけだろ。
どういう原理化だけでもいい。

0455デフォルトの名無しさん

2007/05/08(火) 23:49:44

>454
>具体的に示してくれればいい

断る。暇じゃないんだ。

0456デフォルトの名無しさん

2007/05/08(火) 23:57:29

俺も基幹ロジックが何を指してるのか知りたい。ググっても
>>443が言ってるのが何のことかさっぱりわかんね。

何かの分野での常識用語ですか？

0457デフォルトの名無しさん

2007/05/09(水) 00:24:32

なんだよただのあほか

0458デフォルトの名無しさん

2007/05/09(水) 00:50:49

自分で職人技とか言っちゃうのも痛い

0459デフォルトの名無しさん

2007/05/09(水) 00:54:33

分からないならこなくていいよ

0460デフォルトの名無しさん

2007/05/09(水) 01:04:38

マルチスレッドってI/Oレイテンシとかシーケンシャルで重い処理の
処理時間を隠蔽するために使うもので、乱用するもんじゃないとか
思ってたんだけど。俺の感覚が間違ってるのか。

0461デフォルトの名無しさん

2007/05/09(水) 01:41:35

マルチは使いこなせば最強馬だが
下手に使うと振り落とされる感じが強い

暴れ馬だな

0462デフォルトの名無しさん

2007/05/09(水) 01:54:44

コードサイズを小さくって、マルチスレッドとダイナミックリンクの話を混同してない？
オブジェクト指向の再利用とも違うよね？

マルチプロセッサとかで十分マルチスレッドを処理するハードが有れば有効だけど、２コア程度ならどうせ他のプログラムの処理も行ってるしシングルスレッドのほうが早くないか？
HTが疑似２コアに見せてて、２コア用にマルチスレッドするとパイプラインが詰まって遅くなったりするし。

ゲームなんてシングルスレッドで十分だろ。
昔から描画間隔内にプログラム詰め込んで同期取って来たじゃん。
メールがマルチスレッドって嬉しいのか？
どうせ表では送信中ですの砂時計出してるだろ？

職人技ワロタ。どこの自称職人？

0463デフォルトの名無しさん

2007/05/09(水) 02:33:58

全力で食いつきすぎ。もうちょっと要点を絞ろうぜ。最後の一行だけでいい。

0464デフォルトの名無しさん

2007/05/09(水) 02:34:04

>>462
2chブラウザがハングして長文消えた・・・orz
すんごいはしょって書くけど極論だね。スレッド化は用途次第。
スレッドにする対象が見極められるならシングルコアだろうと
ハイパースレッディングだろうとそれなりに役に立つ。

メールクライアントの話はスレッド化に適さない例をわざわざ
選んでいる。適切だとは言えないな。

0465デフォルトの名無しさん

2007/05/09(水) 03:39:18

＞２コア程度ならどうせ他のプログラムの処理も行ってるしシングルスレッドのほうが早くないか？
甘いな。やってみれば判ることではあるが。

0466デフォルトの名無しさん

2007/05/09(水) 04:18:24

>>455
> 暇じゃない

自分の書いたマルチスレッドのコードで多数発生した不具合を始末している最中ですか?

0467デフォルトの名無しさん

2007/05/09(水) 07:12:01

>462
ダイナミックリンク笑った。
おまえ、組み込みってゲームしかやった事無いだろ。世間知らずだな。

>466
おまえは、仕事で使っているソースを、こんなところに張れるとでも思ってるのか?
秘守義務もしらない、アマチュアか。

メンテナンスしにくい -> わかりにくい -> わかりやすく書いて出せ。

おまえ、手間を考えてクレよ。ゆとり世代は想像力が無くて困る。

0468デフォルトの名無しさん

2007/05/09(水) 07:46:12

どういう原理かだけ書けよｗ
今度はゆとりかよ

0469デフォルトの名無しさん

2007/05/09(水) 07:46:54

どう見ても、一人だけ違う世界に居るようですが。

0470デフォルトの名無しさん

2007/05/09(水) 07:48:09

また空気の読めないキチガイか。

0471デフォルトの名無しさん

2007/05/09(水) 07:48:25

意味不明の例だけだすやつがあほ
あれで意味を理解できるやつはいないだろ
あれで説明になってると思ってるお前はゆとり以下だ

0472デフォルトの名無しさん

2007/05/09(水) 08:15:31

お花畑モード全開ですね。

0473デフォルトの名無しさん

2007/05/09(水) 09:09:31

おもしろい主張をする
↓
説明を要求される
↓
守秘義務を盾に拒否

いいね、この流れ

0474デフォルトの名無しさん

2007/05/09(水) 09:41:27

基幹ロジックって何か教えてくり

0475デフォルトの名無しさん

2007/05/09(水) 10:59:41

秘守義務(←何故か変換できない)ってどこの言葉なんだろうな。

0476デフォルトの名無しさん

2007/05/09(水) 11:03:59

秘守義務w

0477デフォルトの名無しさん

2007/05/09(水) 11:07:23

うお、普通に読み流してたが秘守かよ。

0478デフォルトの名無しさん

2007/05/09(水) 12:15:47

秘守義務はいいから基幹ロジックって何か教えてくり

0479デフォルトの名無しさん

2007/05/09(水) 13:35:45

だめだ。どうやっても
>>443が理解できない。
1. 一つの関数をパラメータ変えて2回実行する。
2. 一つの関数をパラメータ変えて2つ並列に実行する。
という2者を比べて、2の方がコードが減るという謎の実行環境があるってことなのか。
普通に考えるとスレッド作成と、待ち合わせの分2の方がコードが増えると思うが、
秘守義務で守られた基幹ロジックでは違うんだろう。

0480デフォルトの名無しさん

2007/05/09(水) 14:23:34

> 暇じゃない
典型的な負け犬の捨て台詞ﾜﾛｽ
まぁ簡単に逃げられるのは2chのいいところだな。

0481デフォルトの名無しさん

2007/05/09(水) 14:44:49

だから基幹ロジックって何か教えてくりよ。別に本人じゃなくても
知ってる人なら誰でもいいから

0482デフォルトの名無しさん

2007/05/09(水) 15:31:41

応答速度か計算処理量を重視するかで変わってくるんでないの?
互いに干渉のほとんどないようなのだと楽にスケールできるタイプのもあれば、
同期によって落ちやすくなるのもあるしさ。

非メモリ空間への読み書きみたいなのが発生すればちっとは変わるの?
そもそもその辺はosがカバーしてるのでしょうか。

0483デフォルトの名無しさん

2007/05/09(水) 19:09:31

>>460
ちゃんとやると結構多くの種類の応用で性能面から多用することになるよ。
例えば沢山のイメージファイルのサムネイル作成やりサイズ処理等は
マルチスレッド化しないと遅くて話にならない。

シングルコアの場合でもIO待ちの間にかなりの計算ができるし、
マルチコアならさらに差が出てくる。

んでスループットを上げるという観点からみると、SMTやコアの数とI/O待ち時間を
考慮した適当な数のスレッドプーリングで実装する。
( IOCP が使えれば IOCP でも良いけど)

スループットより個々の処理のレスポンスを上げたい場合は、
非効率になることを承知の上でそれを超える数のスレッドを容赦なく使う。
(この場合メモリもいっぱい載せてもらう)

UI 側処理を継続させるために UI スレッドとワーカスレッドを分離するってのは
クライアントアプリではほぼ必須の処理だけど、これはなんというか奥深さがなくて、
ここで語るほどの技法や信仰もないように思う。

>>482
>同期によって落ちやすくなるのもあるしさ。
レースコンディションや計算時の依存関係が沢山あって上手に多重度を上げるのが
難しい処理ってのはあると思うけど、落ちやすくなるってのはPGの質が悪いだけのような気がする。
たぶん自称「職人」を使わなければOK

0484デフォルトの名無しさん

2007/05/09(水) 20:44:19

基幹ロジックﾜﾗﾀ

0485デフォルトの名無しさん

2007/05/09(水) 20:49:59

>>484
基幹ロジック教えてくり

0486デフォルトの名無しさん

2007/05/09(水) 22:40:42

> これはなんというか奥深さがなくて、

で、で、で、でた～～～～～～～～～～～～！！
「奥が深い」
でた～～～～～～～～～～～～～～～～！！！

0487デフォルトの名無しさん

2007/05/09(水) 23:54:37

>>486
くだらなすぎ。
帰れ基幹ロジック野郎

0488デフォルトの名無しさん

2007/05/10(木) 03:28:26

We are the 基幹ロジック. You will be assimilated. Resistance is futile

0489デフォルトの名無しさん

2007/05/10(木) 04:57:06

modern multithreadingって洋書の邦訳ってありましたっけ？
これ教科書的に使えて初心者にお薦めのような気がするのですが

0490デフォルトの名無しさん

2007/05/10(木) 05:02:39

つか今どきこんなしょうもねーﾃﾞﾗﾜﾛｽ基幹ロジックって使ってる奴いるの？
ライブラリ買ってくるかICCで済ませる方がﾌﾟｷﾞｬｰとか言われなくて済みそう

0491デフォルトの名無しさん

2007/05/10(木) 09:59:51

マルチスレッド基幹ロジック　でぐぐってもこのスレが最初にヒットするんだが…
基幹ロジックとはなんなのだろう？？

>>490
基幹ロジックの意味を知ってるならぜひとも教えて

0492デフォルトの名無しさん

2007/05/10(木) 11:19:25

×基幹(きかん)ロジック

○基幹(もとのり)ロジック

0493デフォルトの名無しさん

2007/05/10(木) 12:10:03

今時基幹ロジック使ってないやついるんか？
MoFのサイトに載ってるよ

0494デフォルトの名無しさん

2007/05/10(木) 19:57:36

- ついて行けてますから、説明してください。

- ついて来れてないじゃん。んなヤツに説明すんのは時間の無駄。

- 「うきききーーーーっ」　と、ファビョーン

- つまんね <- いま、ここ。

0495デフォルトの名無しさん

2007/05/10(木) 22:42:06

そもそも最初の「わかりやすい例」とかいうもの自体、誰一人わからないわけだが。
おそらく本人も理解していないだろう。

最初からおかしな奴だとは思っていたが、こういう話でハッタリやデタラメが通じると
思ってるんならそうとうお目出たいぞ・・・

0496デフォルトの名無しさん

2007/05/11(金) 00:40:50

>>493
基幹ロジック　MoF　でググッても分かりませんでした。
何のことか教えて欲しいです。

0497デフォルトの名無しさん

2007/05/11(金) 10:06:19

>>466
晒せないない公開していいソースを別に作って出せばいい
最後まで付き合えないなら最初から黙ってろ

0498デフォルトの名無しさん

2007/05/11(金) 10:10:51

気違いと厨がマルチスレッドしてるスレはここですか?

0499デフォルトの名無しさん

2007/05/11(金) 17:48:06

- ついて行けてますから、説明してください。

- ついて来れてないじゃん。んなヤツに説明すんのは時間の無駄。

- 「うきききーーーーっ」　と、ファビョーン

- つまんね

- 「うきききーーーーっ」　と、またまた、ファビョーン

- つまんね <- また、ここ。

0500デフォルトの名無しさん

2007/05/11(金) 18:14:19

以降、気違いはスルーで

0501デフォルトの名無しさん

2007/05/11(金) 21:55:24

DualCoreが増えて、マルチスレッドがブームになり、デッドロックが流行語大賞になる予感。

0502デフォルトの名無しさん

2007/05/12(土) 22:25:35

以降、デッドロックはスルーで

0503デフォルトの名無しさん

2007/05/12(土) 22:36:55

デッドロク

0504デフォルトの名無しさん

2007/05/13(日) 08:25:09

秘守義務はさすがに要求されたことは無いな。契約時の語句の間違いは致命的だ(w

沢山のイメージファイルのサムネイル作成やりサイズ処理等でMS化してしまうとCPUを占有してしまうので、マルチユーザを前提とした環境では向いてないな。
レン鯖とか多人数で共用してる鯖だと迷惑。

0505 ◆0uxK91AxII

2007/05/13(日) 08:45:20

以降、>>504もスルーで。

0506デフォルトの名無しさん

2007/05/13(日) 11:46:50

>>505
すまん、一つだけ突っ込ませてくれ。
＞MS化

0507デフォルトの名無しさん

2007/05/13(日) 11:50:10

マイクロソフト化だろ？
エクスプローラのサムネイル表示の遅さを指摘しているものと思われ。

0508デフォルトの名無しさん

2007/05/13(日) 11:51:21

きっとモビルスーツ化のことだろう。

0509デフォルトの名無しさん

2007/05/13(日) 18:06:25

maruti sureddo

0510デフォルトの名無しさん

2007/05/13(日) 19:54:08

スレッドセーフかつ高速なスレッディングプログラミングをライティングするには
どういうブックをリーディングすればいいのでしょうか。

0511デフォルトの名無しさん

2007/05/13(日) 20:26:12

マルチスレッドに関しては、入門書以上のものは見たことないな。

0512デフォルトの名無しさん

2007/05/13(日) 22:43:35

理論ばっかだね。
実際の実装に対するプログラミング手法の解説って見た事無い。

0513デフォルトの名無しさん

2007/05/13(日) 22:51:01

”マルチスレッドプログラミング　入門”も
”オブジェクト指向プログラミング　入門”って感じする

0514デフォルトの名無しさん

2007/05/13(日) 23:32:39

>>510
スレッドセーフって、共有エリアへのアクセスの排他制御とか、
スタティック変数で値を保持する非リエントラントな関数コールの
ラップ（かぶり）抑止などか？

0515デフォルトの名無しさん

2007/05/14(月) 00:39:41

無闇にやると、関数にしろメモリにしろ整合取れない -> スレッディング以前の問題
整合を気にしつつ穏当に実装 -> 遅くて洒落にならん

どうすりゃいいのよ
このままだと、パーティクル処理とかメインに絡まないサブスレッドしか走らせられない。
何が何でも意地でもメインスレッドをマルチ処理しなけりゃメンツに関わる

0516デフォルトの名無しさん

2007/05/14(月) 02:54:32

コード領域をどうしても小さくしたい場合に使うって書いただろ。
何が何でも、っておまえはやりたい事はなんなんだ?

0517デフォルトの名無しさん

2007/05/14(月) 03:20:26

>>515
ゲーム屋？ゲームでマルチプロセッサを有効に使うのは結構難しいんだよね。

以前、カプコンが画期的な手法でデュアルコアに最適化した例があるよ。
ttp://www.4gamer.net/news/history/2005.12/20051221234248detail.html
ttp://www.watch.impress.co.jp/game/docs/20051221/onidual.htm
このとき受けた衝撃は凄かった。

0518デフォルトの名無しさん

2007/05/14(月) 08:40:45

ちょw
多重起動防止外しただけじゃねーか。

0519デフォルトの名無しさん

2007/05/14(月) 08:47:10

どこが画期的なのか全然分からない。

0520デフォルトの名無しさん

2007/05/14(月) 08:50:08

多重起動防止を外したからデュアルコアを両方とも使えるようになっただけにしか見えないのに、
さも凄いことのように記事を書いていることに衝撃を受けた。

0521デフォルトの名無しさん

2007/05/14(月) 10:28:02

>>519
自分のプロダクトをデュアルコア対応にする最速の方法だぞ。
画期的すぎる。しかもこの方法は4コアでも8コアでも通用する。

ただし、ユーザーに見捨てられる。

0522デフォルトの名無しさん

2007/05/14(月) 10:40:55

洒落や冗談でなく、1ジョブ1プロセス型のアプリケーションなら一番手っ取り早いね。
2coreXeon*2の環境でテストしたら、4プロセスまでは処理速度がリニアに向上したケースもある。

0523デフォルトの名無しさん

2007/05/14(月) 10:54:04

>>521
その目的に対しては有効な手法だとは認めるが、
期待してリンク見たのに、感想としては、正直がっかりだ。

0524デフォルトの名無しさん

2007/05/14(月) 10:57:03

そのうちRPGかなんかで、別プロセスでアイテム一覧プログラムを動かして「DualCore最適化」と言い張ったりして。

0525デフォルトの名無しさん

2007/05/14(月) 11:04:10

そんなことよりマルチスレッド化してコード領域が小さくなる件についてkwsk

0526デフォルトの名無しさん

2007/05/14(月) 11:15:17

>>525
自分で複数タスクを同時処理するためのフレームワークのコード書くより、
OSが提供するのを利用したら自分の書くコードが減るからじゃないの？

0527デフォルトの名無しさん

2007/05/14(月) 12:52:55

>>526
え、そういうことだったの？

つまり自分で（シングルスレッドの）イベント駆動型マルチ
タスク処理書くより、OSのマルチスレッドAPI使ったほうが
コードが簡潔になって小さくなるってことだったのか。

まあそりゃ、確かにそういう状況もあるな。

0528デフォルトの名無しさん

2007/05/14(月) 14:33:36

>>527
ごめん、過去レス見ずに書いた。
言い出した人は、マルチスレッドとは関係のないコードサイズ縮小の一手法しか挙げてないね。
その上、基幹ロジックって言ってるから、それを外部設計にも応用しましたってことだと思う。PG泣かせのバカSEの典型かも。
どういう意図で言ったかは本人に聞くしかないと思う。

0529デフォルトの名無しさん

2007/05/14(月) 14:42:57

＞マルチスレッドとは関係のないコードサイズ縮小の一手法
これがわからん…。上のほうでサブルーチン化することとの
比較みたいなのあるけど、サブルーチン化する以上にマルチ
スレッド化で小さくなるケースなんてあるの？

0530デフォルトの名無しさん

2007/05/14(月) 15:35:01

上のサブルーチンの例はどうでもいいなら、
>>526　とか、
煩雑な処理をマルチスレッド化したらコードがシンプルになる例ならよくあるでしょ。

>サブルーチン化する以上に
条件によって千差万別なのに、比較しても意味ないよ。
上のサブルーチンの例はただの勘違いだと思うのでスルーしていいと思う。

0531デフォルトの名無しさん

2007/05/14(月) 16:20:55

まあそんなのは当たり前の話で、
ことさら携帯などの環境ではとか
特殊な話はよくわからんな。

メンテナンス性を非常におとすから、
あまりお勧めできない話らしいし。

ってわけで昔の話は無視しとけ。

0532デフォルトの名無しさん

2007/05/14(月) 18:12:27

>>517
なんだよカプコンって言うからこっちかと思ったじゃないか
http://www.watch.impress.co.jp/game/docs/20070131/3dlp.htm

0533デフォルトの名無しさん

2007/05/15(火) 00:14:46

517はジョークというか皮肉だから、そんなに真面目につっこまないでくれw

インタビューのときに偉そうなことを言っておいて、3ヶ月後に出てきたのがあれだったんだよ。
ttp://www.4gamer.net/news.php?url=/news/history/2005.12/20051221234248detail.html

多重起動のチェックを外しただけだから、2つ起動できても音が出るのは片方だけだし、
操作系も特に修正していないという酷い状態。

ようするに、カプコンさえも既存のゲームのマルチスレッド化はさじを投げたってことだね。

0534デフォルトの名無しさん

2007/05/15(火) 00:33:50

こいつは笑うしかない

0535デフォルトの名無しさん

2007/05/15(火) 00:44:41

まあそれは、あれだけど
リアルタイムのゲームでマルチスレッド化して恩恵得られるのってどこらへん?

0536デフォルトの名無しさん

2007/05/15(火) 00:52:37

マルチスレッド自体が重要ってんじゃなくて、
単にマシン資源をできるだけ活用するってとこだわな。
※もちろんそれをするためにはマルチスレッドが必要だけど

そういう意味でスペックを想定できないPCでは難しいよね。

0537デフォルトの名無しさん

2007/05/15(火) 02:41:06

533のリンク先間違ってた。
ttp://www.4gamer.net/news/history/2005.09/20050918003756detail.html
こっちのことね。(523のリンク先からも飛べるが)

>>535
デュアルコアなら、上手く2つのスレッドを使えば倍近いパフォーマンスが得られる。
今は動作クロックの向上よりも、コア数を増やしてパフォーマンスを稼ぐ傾向にあるから、
そういう方向の最適化が求められている。
元が並列的な処理でなくても、工夫して並列に処理させたり。

0538デフォルトの名無しさん

2007/05/15(火) 11:21:42

ロックフリー

0539デフォルトの名無しさん

2007/05/15(火) 21:59:51

～の処理を「２コア目に回す」なんてPCでできるのかね？
スレッドにはできるだろうが、そのスレッドがCore1で走るか
Core2で走るかはOSのみぞ知るってところじゃないの？

0540デフォルトの名無しさん

2007/05/15(火) 22:11:22

Win32ならSetThreadAffinityMask()で指定できる

0541デフォルトの名無しさん

2007/05/16(水) 01:00:13

Solaris ならどのスレッドをどのコアで動かすか細かく指定出来るよ。
グルーピングで指定も出来るし、スレッド毎に指定する事も出来る。
プロセスの外からスレッドの割り付けを変更する事ももちろん可能。

0542デフォルトの名無しさん

2007/05/16(水) 02:01:19

rdtsc
rdtscp

0543デフォルトの名無しさん

2007/05/16(水) 09:28:36

M:Nが絶滅するらしいね

0544デフォルトの名無しさん

2007/05/16(水) 09:50:35

MN(LW)P

0545デフォルトの名無しさん

2007/05/19(土) 05:57:44

ﾌﾟﾛｸﾞﾗﾏやってると、ちょい前のﾚｽの人の様にｺﾝﾊﾟｲﾗみたくﾋﾟｰﾋﾟｰ鳴く生き物になんの？

0546デフォルトの名無しさん

2007/05/19(土) 13:25:50

よそで聞け

0547デフォルトの名無しさん

2007/05/19(土) 18:16:59

ここでjavaのthreadの話していい？

0548デフォルトの名無しさん

2007/05/19(土) 18:41:00

いいよ

0549デフォルトの名無しさん

2007/05/19(土) 19:32:56

javaのthreadはsunが作ったから世界一なのに、
なんで他の言語で無様な模倣品を作り続けるの？

ぜんぶjavaになってしまえばいいのに。

以上です。

0550デフォルトの名無しさん

2007/05/19(土) 22:26:09

ビル・ゲイツ　「 SUNの Javaランタイムは二度と見たくない」

0551デフォルトの名無しさん

2007/05/19(土) 22:33:44

Bill が作った言語のランタイムは見てみたいw

0552デフォルトの名無しさん

2007/05/19(土) 22:59:55

N-BASICとかがそうだろ。当時としてはよくできてるんじゃないかな。

0553デフォルトの名無しさん

2007/05/19(土) 23:02:05

アァスマン、ソースが見たいって事ね。

0554デフォルトの名無しさん

2007/05/20(日) 00:08:32

大丈夫、当時のBASICは皆アセンブラで書かれていたから
逆アセンブルすればソースになる。

0555デフォルトの名無しさん

2007/05/20(日) 00:15:17

そうなのけ?
メモリが 256KB で十分な時代ならそんなもんか。

0556デフォルトの名無しさん

2007/05/20(日) 00:38:42

256KBなんて贅沢な。
16KBを必死にやりくりしてた頃が懐かしい。

0557デフォルトの名無しさん

2007/05/20(日) 00:58:41

GVRAM領域にコード置いたり。

0558デフォルトの名無しさん

2007/05/20(日) 01:39:22

当時、メモリ空間は、64KBだ。
RAMが64KBなんて超高級機だ。

0559デフォルトの名無しさん

2007/05/20(日) 02:11:16

ROM8K
RAM8K

0560デフォルトの名無しさん

2007/05/20(日) 02:21:02

>>553
当時の人はOPコード暗記してるので、読むだけならバイナリのまま読んでた。
だから、そのままで読んで問題なし。

0561デフォルトの名無しさん

2007/05/20(日) 04:00:12

最初に触ったのは富士通のFM-7だったかな
N88BASICだった

あれってメモリいくつだったんだ?

0562デフォルトの名無しさん

2007/05/20(日) 04:36:26

FM-7がN88BASICのわけねぇっしょw

0563デフォルトの名無しさん

2007/05/20(日) 04:36:52

こらこら
Nxx-BASICはNECだ。

0564デフォルトの名無しさん

2007/05/21(月) 11:30:59

MS-DOS版N88日本語BASIC(86)コンパイラー

長い名前だったｗ

0565デフォルトの名無しさん

2007/05/21(月) 12:32:11

32KB

0566デフォルトの名無しさん

2007/05/21(月) 16:08:28

FM-8は64kBフル実装（4kBはアクセスできない）だったけど
FM-7は32kBだったの？

0567デフォルトの名無しさん

2007/05/21(月) 17:09:53

8ビットCPUでマルチスレッドなんかできるの？

0568デフォルトの名無しさん

2007/05/21(月) 17:14:10

FM-7の方が後発なのに削るなんてことあるかいな。
尤も、6809*2の変態構成だった記憶はあるが。

0569デフォルトの名無しさん

2007/05/21(月) 17:23:59

6809 と OS-9 はすばらしかった。
マルチスレッドではないが、メモリ保護つきマルチプロセスは実現してた。

0570デフォルトの名無しさん

2007/05/21(月) 17:41:43

7は8のほぼアッパーコンパチ。バブルメモリとか普及しなかったものは削られたけど。

>>569
当時はUnix（SystemVと4.2BSDの頃？）にもマルチスレッドってなかったような。

0571デフォルトの名無しさん

2007/05/21(月) 17:52:46

8ビットマシンでメモリ保護ついてる機種なんかあったんだ。

0572デフォルトの名無しさん

2007/05/21(月) 18:10:23

>>571
http://ja.wikipedia.org/wiki/MB-S1#S1
> # MMU搭載により1MBのアドレス空間を実現
> * メモリ空間の保護が可能。

0573デフォルトの名無しさん

2007/05/21(月) 19:51:52

68000なんて公証16ビット中身32ビットなんて変態CPUもあったなぁ
商売損してるよなぁ

0574デフォルトの名無しさん

2007/05/21(月) 20:29:53

>>573
http://www.st.rim.or.jp/%7Enkomatsu/hitachi/HD6309.html

変態かどうかは知らないがマニアック度は間違いなくこっちだろ。
先輩は「喚装してない OS9er はいないハズ」とまで豪語してた(w

0575デフォルトの名無しさん

2007/05/21(月) 20:41:34

日本ではz80系がメジャーだと思っていたのに、こんなに6809系マンセーな奴がいたのか。

0576デフォルトの名無しさん

2007/05/21(月) 20:45:31

2MHz とか 3MHz とかって今考えると泣けて来るな。
クロックが 100MHz を超えた時は感動したもんだったが。

0577デフォルトの名無しさん

2007/05/21(月) 21:33:44

おまえらマルチスレッドなんてほぼない時代の話すんなよ

0578デフォルトの名無しさん

2007/05/21(月) 21:45:05

マルチスレッドは甘え。

0579デフォルトの名無しさん

2007/05/21(月) 22:25:25

9才ttp://lovelyidol.jp/shop/cyber/jacket_folder/CPLO-002_800.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/SCDV-10139_500.jpg
10才ttp://lovelyidol.jp/shop/nenrei/jacket_folder/BKDV-00218_800.jpg
　　　ttp://www.idol-club.com/pic/dvd/clr/NDCL-032b.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/0363_800.jpg
11才ttp://lovelyidol.jp/shop/imouto/jacket_folder/IMOB-021_800.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/CPSKY-004_800.jpg
　　　ttp://www.idol-club.com/pic/dvd/fuga/NDFG-024b.jpg
　　　ttp://lovelyidol.jp/shop/cyber/jacket_folder/CPSKY-024_800.jpg
12才ttp://pics.dmm.co.jp/mono/movie/n_681kboot03/n_681kboot03pl.jpg
　　　ttp://www.shinko-sha.co.jp/shopping/m_shop/p_image/0307-6a.jpg
　　　ttp://lovelyidol.jp/shop/cyber/jacket_folder/CPSKY-020_800.jpg
13才ttp://www.idol-club.com/pic/dvd/bunka/NDBK-269b.jpg
　　　ttp://lovelyidol.jp/shop/fuga/jacket_folder/BKDV-00219_800.jpg
　　　ttp://lovelyidol.jp/shop/imouto/jacket_folder/IMOB-019_800.jpg
14才ttp://www.idol-club.com/pic/dvd/take/NDTK-283b.jpg
　　　ttp://lovelyidol.jp/shop/shinkousha/jacket_folder/SCDV-22006_800.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/BKDV-00203_800.jpg
15才ttp://lovelyidol.jp/shop/nenrei/jacket_folder/KODV-12_500.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/DMSM-7169_800.jpg
　　　ttp://lovelyidol.jp/shop/nenrei/jacket_folder/idol-025_800.jpg
16才ttp://www.idol-club.com/pic/dvd/enet/NDEF-1086b.jpg

0580デフォルトの名無しさん

2007/05/22(火) 08:45:00

>>567
16bitだが98DOSでは常駐という手法で
マルチスレッドもどきが出来た記憶。

0581デフォルトの名無しさん

2007/05/22(火) 10:26:05

>>580
DOSの常駐(TSR)は、コオペラティブマルチタスク。マルチスレッドではない。

0582デフォルトの名無しさん

2007/05/22(火) 10:37:11

>>581
ｲﾝﾀｰﾊﾞﾙﾀｲﾏ割り込みでｽﾃｰﾄﾏｼﾝうごかせば…
でもじゃねーか

0583デフォルトの名無しさん

2007/05/22(火) 11:07:47

マルチタスクとマルチプロセスとマルチスレッドの違いが分かりません。

0584デフォルトの名無しさん

2007/05/22(火) 11:29:50

マルチタスクは別々のプロセスが同時に、、、
ここで言うマルチプロセスはプロセス（メモリ）空間が別々な複数の同じプロセス、という意味かな
マルチスレッドはそれぞれのスレッドのプロセス（メモリ）空間は同じ

0585デフォルトの名無しさん

2007/05/22(火) 11:49:37

割り込みで別処理するだけなら、8bitCPUでもできる罠。

0586デフォルトの名無しさん

2007/05/22(火) 11:54:25

仮想メモリ空間が作れない処理系では、
マルチスレッドはおろかマルチプロセスもできないってことですか。

0587デフォルトの名無しさん

2007/05/22(火) 12:25:48

リソースの共有の程度の話だから
そこまで厳密に考えなくていいんじゃないの

0588デフォルトの名無しさん

2007/05/22(火) 12:32:38

>>586
つ[Concurrent CP/M-86]

0589デフォルトの名無しさん

2007/05/23(水) 22:11:44

マルチタスク
　複数のアプリケーション（タスク）が平行して動く。
　１タスクは１プロセスとは限らない。

マルチプロセス
　複数のプロセスが平行して動く。１プロセスが１タスク
　とは限らない。

マルチスレッド
　複数のスレッドが平行して動く。１プロセス＝最低でも
　１スレッド。

0590デフォルトの名無しさん

2007/05/23(水) 23:22:54

× 平行
○ 並行

0591デフォルトの名無しさん

2007/05/24(木) 00:25:38

閉口

0592デフォルトの名無しさん

2007/05/24(木) 20:57:58

_beginthreadexでワーカスレッドを起動させたあと
ワーカスレッドがreturnする前に親スレッドでCloseHandleしても
問題ないでしょうか？
実際のところ_beginthreadexの直後でCloseHandleしても
ワーカスレッドは動き続けているようなのですが、
リソースリークが気がかりなのです。

0593デフォルトの名無しさん

2007/05/24(木) 21:41:23

ハンドルが必要がなければ、_beginthreadexした直後に
CloseHandleするもんだよ。リークなんかしない。

0594デフォルトの名無しさん

2007/05/25(金) 00:57:07

>>593
592さんとは別の人なんですが、_endthreadexを呼び出す前に
「CloseHandleを呼び出してもいい」という点についてMSDNとかで明言されているのですか？
お手数でなければ教えていただきたいのですが？
MSDNのCloseHandleの説明をみるかぎり
ttp://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpipc/html/_win32_closehandle.asp
スレッド終了->CloseHandleという形で呼び出すと思っていたのですが。

0595デフォルトの名無しさん

2007/05/25(金) 01:32:00

ハンドルの意味わかってねーなー

0596デフォルトの名無しさん

2007/05/25(金) 01:41:24

>>594
Windowsのスレッドオブジェクトは、
・そのスレッドを示すハンドルがすべてクローズされ、かつ
・スレッドの実行が終了している
ときに消滅する。CloseHandle()をいつ呼んでも実行中のスレッドが死
んだりすることはない。

0597594

2007/05/25(金) 01:41:44

>>595
分かっていないからお聞きしている訳で…

0598594

2007/05/25(金) 01:54:52

>>596
ありがとうございます。そのような情報はどこ(MSDとか書籍)に記述してあるのでしょうか？？

たとえば私が>>594であげたリンクによると
＞「最初にスレッドを終了」し、次にそのスレッドのすべてのハンドルを閉じなければなりません。
括弧は引用者(筆者)による強調。
最初にスレッドを終了するという点をわざわざドキュメントとして記述してあるということは、
スレッドの終了を先にしなければならないといけないと思ったのですが？
差し支えなければもう一度教えていただけないでしょうか？

0599デフォルトの名無しさん

2007/05/25(金) 02:06:36

>>598
ハンドルを閉じてからスレッドを終了してはならない、とは書いてない
だろう？

0600594

2007/05/25(金) 02:18:35

>>599
はい、確かにその点については記述されておりません。
私の勘違いで時間を無駄にさせてしまい。すみませんでした。
教えてくださり、ありがとうございました。

0601 ◆0uxK91AxII

2007/05/25(金) 08:58:21

変数を減らすなんていう下らない事の為に、
論理的に誤った記述を行うのは如何なものか、と。

>>592 >>594
問題は無いらしい。
MSは明言していない。

0602デフォルトの名無しさん

2007/05/25(金) 10:15:34

なんで変数を減らす為なんて勝手な解釈を加えてるんだ？
誰もそんなこと言ってないし。

実行中にハンドルをCloseしていいことはMSDNライブラリにも書いてある。
http://msdn2.microsoft.com/en-us/library/ms810438.aspx
http://msdn2.microsoft.com/en-us/library/ms810425.aspx
http://msdn.microsoft.com/archive/en-us/dnarw98bk/html/makingmodifyingthreads.asp

CloseHandleの説明も、英語だとどこにも「最初に」なんて書いてないんだけどね。
Closing a thread handle does not terminate the associated thread. To remove a thread object, you must terminate the thread, then close all handles to the thread.

メインスレッドと同期する必要のないスレッドは、さっさとハンドルを
Closeしておいた方がいい。

0603デフォルトの名無しさん

2007/05/25(金) 10:24:12

592です。
みなさまご回答ありがとうございます。
おかげさまでたいへんすっきりしました。

>>594さん
私が寝てる間に疑問に思っていたことを
投げかけてくれてありがとうございます。

0604 ◆0uxK91AxII

2007/05/25(金) 10:45:50

>>602
勝手な解釈の部位は、誰にも宛てていない:b

＞実行中にハンドルをCloseしていいことはMSDNライブラリにも書いてある。
明言している箇所を抜き出しなさい。
探すのが面倒だからね。

0605デフォルトの名無しさん

2007/05/25(金) 11:18:57

この糞鳥餅は目が見えないらしい

0606デフォルトの名無しさん

2007/05/25(金) 19:43:59

日本語で噛みくだいて訳して欲しいんだろ

厨にはよくある事

0607デフォルトの名無しさん

2007/05/26(土) 12:12:51

gcc4.2のOpenMPコードヘボヘボでだめじゃんw

0608デフォルトの名無しさん

2007/05/26(土) 16:00:26

マルチスレッドが無ければ世の中のデスマの35%は無くなる。

0609デフォルトの名無しさん

2007/05/26(土) 16:37:19

無くならない。

なぜなら、別の原因でデスマるから。

0610デフォルトの名無しさん

2007/05/26(土) 17:36:05

コードの書けないSEがいなければ、デスマの80%は無くなる。

0611デフォルトの名無しさん

2007/05/26(土) 20:34:07

>>610
我が国の中傷システム開発会社の特徴が、どこでも入社半年でSE教育を強制され
プログラマを見下ろす事を刷り込まれる。
やがて殿様状態になった自分に気が付き、右往左往して何人も辞めてゆく・・・

0612デフォルトの名無しさん

2007/05/26(土) 20:48:24

そういうのはマ板でやってくれないか

0613デフォルトの名無しさん

2007/05/27(日) 15:52:11

この To remove 以下は前の文章の補足として読まなければならない
ような希ガス

0614デフォルトの名無しさん

2007/06/01(金) 21:45:24

あるタスクをスレッドに分解する手法って何がある？

0615デフォルトの名無しさん

2007/06/01(金) 22:28:21

どんなタスク？

0616デフォルトの名無しさん

2007/06/02(土) 01:45:02

おーい、>>614 の為にエスパー呼んできてー

0617デフォルトの名無しさん

2007/06/02(土) 09:20:47

>>614 http://www.anet-web.com/ei/ei-ant.jpg

0618デフォルトの名無しさん

2007/06/02(土) 15:29:08

　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼
　　　　　／　　─　　 ─＼
　　　　／　　（●）　（●）＼　　「ﾃﾗﾜﾛｽｗｗｗｗｗｗｗうぇうぇｗｗｗｗ」・・・・と
　　　　|　　　　（_。人。_）　　 |　＿＿＿＿＿＿＿_
　　　＼　　　　｀ ⌒´ 　 ,／　.| |　　　　　　　　　　|
　　　　ノ　　　　　　　　　　　＼　| |　　　　　　　　　　|
　／´ 　　　　　　　　　ｶﾀ.　　 | |　　　　　　　　　　|
　|　　　　ｌ　　　　　　　ｶﾀ　| |　　　　　　　　　　|
　ヽ　　　 -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__|
　　ヽ＿＿＿＿,ノγ⌒ヽ)ニニ-￣　　　| |　　|　　　　　＿＿＿_

0619デフォルトの名無しさん

2007/06/02(土) 15:38:12

機能分割とか領域分割とかってthreadに関係あるの？

0620デフォルトの名無しさん

2007/06/02(土) 15:43:21

gccもopenmpに対応したっていうのに、いまさらpthreadを学ぶやつってなんなの？

0621デフォルトの名無しさん

2007/06/02(土) 15:58:31

posixの意味はわかってるか？

0622デフォルトの名無しさん

2007/06/02(土) 16:47:08

RHEL 5.0 と RHEL 4.5でシステムの管理できるプロセス・スレッド数ってどうなった？
あと、1プロセスが管理できるプロセス数とか。
こういう情報ってなかなかまとめて公開されてないんだよね。

0623デフォルトの名無しさん

2007/06/02(土) 19:14:18

>>622
そういうのってディストリの話じゃなくてカーネルの制限だろ
てことでカーネルのソース読めばよろし

0624デフォルトの名無しさん

2007/06/02(土) 19:32:08

どこを読めば良いのかヒントぴりーざ

0625デフォルトの名無しさん

2007/06/02(土) 19:34:25

Linux板で聞けば誰か知ってるんじゃね？

0626デフォルトの名無しさん

2007/06/02(土) 20:56:15

ゲ製でみたのは内緒なｗ

0627デフォルトの名無しさん

2007/06/03(日) 03:32:37

Linuxでマルチプロセスを実現したい場合、

メインプロセスでfork()を行う。子プロセス側でexec()系の関数使う。

が一般的なんでしょうか？windows見たいにCreateProcess()があって、
成功失敗を戻り値で判断できるような関数ってLinuxだと用意されていない？

0628デフォルトの名無しさん

2007/06/03(日) 07:08:38

Linuxそのものが失敗だから用意するもない

0629デフォルトの名無しさん

2007/06/03(日) 08:15:14

>>627
system()でバックグラウンド起動すればほぼ同じことができる。
popen()とシェルの機能を使えば更に起動したプロセスのIDも取得できなくはない。

0630デフォルトの名無しさん

2007/06/03(日) 08:52:16

はい
fork と同時に pipe で繋いでプロセス間通信します

0631デフォルトの名無しさん

2007/06/04(月) 15:52:43

しかし、どうも forkって嫌なんだが、そういうこたぁないのか?

0632デフォルトの名無しさん

2007/06/04(月) 16:23:48

ないよ

0633デフォルトの名無しさん

2007/06/04(月) 16:26:40

嫌というのは？
重いから？

0634デフォルトの名無しさん

2007/06/04(月) 16:49:29

fork()は言語の仕様として受け入れられないレベルの機能だから。

0635デフォルトの名無しさん

2007/06/04(月) 17:00:57

Cの言語仕様にはマルチプロセスなんて概念ないからねぇ。

0636デフォルトの名無しさん

2007/06/04(月) 17:01:26

>>634
fork() と C の言語仕様には何の相関もありませんが。

0637デフォルトの名無しさん

2007/06/04(月) 17:55:58

K&RがUnix作ったすぐ後にcを作った。
受け入れられないのはたぶん>634だけ。

0638デフォルトの名無しさん

2007/06/04(月) 20:50:40

プロセスを複製するのはちょっとキモいな
if(fork()==0){
//子
}else{
//親
}
最初見たときは「何じゃこりゃ」と思った記憶がある

CreateProcessとかで明示的に作成する方が
わかりやすいといえばわかりやすい

0639デフォルトの名無しさん

2007/06/04(月) 21:59:25

フォークで複製するのとプロセスを生成するのではまったく意味が違う。

0640デフォルトの名無しさん

2007/06/04(月) 22:07:41

フォークって書くとなんか別のモンみたいだな

ナイフと一緒に使うアレとか

0641デフォルトの名無しさん

2007/06/04(月) 22:19:35

>>627
単にマルチプロセスしたいならexec()系は不要。

exec()系の目的は他の実行イメージへの置き換え、
もしくは自身と同じ実行イメージに置き換えての再起動。

Windowsではプロセスの分岐と実行イメージの
置き換えを分割できないので、不便な事も多い。

fork()とexec()系を組み合わせた挙動が欲しいのならば、
msvcrtのspawn()系のような関数を実装すればいい。

0642デフォルトの名無しさん

2007/06/04(月) 22:26:35

fork() = フォーク
spawn() = スプーン

0643デフォルトの名無しさん

2007/06/04(月) 22:32:41

hash() = 箸

0644デフォルトの名無しさん

2007/06/04(月) 23:15:42

処理を二股に分岐するからfork()なんだが。

0645デフォルトの名無しさん

2007/06/04(月) 23:48:02

へえ。forkって分岐するっていう自動詞でもあるんだ。

The road forks near the river.
道は川のそばで分かれている.

また一歩世界征服の野望に近づいたよ。

0646デフォルトの名無しさん

2007/06/05(火) 00:27:57

どうすれば、中学英語で野望に近づくのかと

0647デフォルトの名無しさん

2007/06/05(火) 00:29:41

世界征服セーラー服

0648デフォルトの名無しさん

2007/06/05(火) 03:51:53

>>644
エラー合わせて３つじゃないの？

0649デフォルトの名無しさん

2007/06/05(火) 04:55:15

>>648
大丈夫、エラーの時には分岐してないから。
あ、もしかして、if分岐と勘違いしている?

0650デフォルトの名無しさん

2007/06/05(火) 06:39:27

深夜に骨肉の争いがあったらしいな

0651デフォルトの名無しさん

2007/06/05(火) 10:41:09

深夜って何時から何時までよ

0652デフォルトの名無しさん

2007/06/05(火) 10:53:39

骨肉の争いって何よ?

0653デフォルトの名無しさん

2007/06/05(火) 11:15:56

>>649
あー「処理」ってのが flow じゃなくて process なのね。勘違いしてた。

0654デフォルトの名無しさん

2007/06/05(火) 21:08:53

getpid
getppid
は出来るのに
子プロセスIDの取得だけなんで面倒なのか

0655デフォルトの名無しさん

2007/06/05(火) 21:14:14

forkの返り血

0656デフォルトの名無しさん

2007/06/05(火) 21:23:57

産んだ子供の面倒ぐらい自分で見ろよ
ってことでね？

0657デフォルトの名無しさん

2007/06/05(火) 21:46:15

リアルでこえーよ

0658デフォルトの名無しさん

2007/06/06(水) 09:36:26

子は1人とは限らないからなー

0659デフォルトの名無しさん

2007/06/06(水) 15:40:27

「ゾンビプロセス」よりは
「水子プロセス」の方がしっくりくる。

0660デフォルトの名無しさん

2007/06/06(水) 18:18:19

そういや、プロセスの水子供養とか、冗談でやってた奴いたな。

0661デフォルトの名無しさん

2007/06/06(水) 18:34:06

今まであの手この手で何人殺したかわからんなマジで

0662デフォルトの名無しさん

2007/06/06(水) 21:03:12

通報しますた

0663デフォルトの名無しさん

2007/06/06(水) 22:00:12

便器に捨てた精子は数知れず

0664デフォルトの名無しさん

2007/06/06(水) 22:48:59

通報…されそうです＞＜

0665デフォルトの名無しさん

2007/06/06(水) 23:49:31

マニュアルページにもwait(2)で子供の骨を拾えと書いてあるから、
骨を拾ってもらえないうちはゾンビでいいんでない?

0666デフォルトの名無しさん

2007/06/06(水) 23:54:31

1982年にわたし待つわとあみんは歌ったが
あれは子供の骨を拾うためだったのか

こわいこわい

0667デフォルトの名無しさん

2007/06/07(木) 00:22:49

>>666
たとえあなたがふりむいてくれなくても……

0668デフォルトの名無しさん

2007/06/07(木) 06:04:05

こっそりと子をプロセスしたんでしょうか
http://www.sankei.co.jp/shakai/jiken/070606/jkn070606012.htm

0669デフォルトの名無しさん

2007/06/07(木) 07:26:45

子プロセスの肥大化に気づかないほど親プロセスがリソース食ってたんだろうな

0670デフォルトの名無しさん

2007/06/07(木) 12:51:11

もともと肥大化してたピザ子プロセスだったんじゃね?

0671デフォルトの名無しさん

2007/06/07(木) 12:52:32

いや、そう言ってるんじゃないか？

0672デフォルトの名無しさん

2007/06/07(木) 13:25:23

いくらピザデブでも妊娠の初期症状一切見逃したのか？
つか生理止まっても気づかねぇとかどうよ

0673デフォルトの名無しさん

2007/06/07(木) 13:45:41

いや気がつかなかったのが両親と教師なのは書いてるけど
本人は知ってたのでは

0674デフォルトの名無しさん

2007/06/07(木) 18:15:31

うちの姉と母はいつだよねーとか言ってるぞ目の前で

0675デフォルトの名無しさん

2007/06/07(木) 21:37:23

>>674
日本でいいよ。

0676デフォルトの名無しさん

2007/06/07(木) 22:04:02

だからうちの姉とと母は「いつだよねー」とか言ってるんだよ俺のも目の前でな

0677デフォルトの名無しさん

2007/06/07(木) 22:11:25

十月十日?

0678デフォルトの名無しさん

2007/06/08(金) 06:00:27

>>627-677
スレ違いな件について

0679デフォルトの名無しさん

2007/06/08(金) 09:39:38

50レスもスレ違いが続いたのか

0680デフォルトの名無しさん

2007/06/08(金) 23:15:44

>>678-680もスレ違い

0681デフォルトの名無しさん

2007/06/10(日) 11:40:13

あーマルチスレッドとマルチプロセスだからスレ違いなのか

0682デフォルトの名無しさん

2007/06/10(日) 19:38:17

NPTスレッドって何よ？Linuxの普通のposix threadととは違うもの？

0683デフォルトの名無しさん

2007/06/10(日) 21:35:51

ググレカス

0684デフォルトの名無しさん

2007/06/10(日) 21:58:12

ククレカレー

0685デフォルトの名無しさん

2007/06/10(日) 22:23:36

ククレカレーって、もうなくね?
みかけないよ?

0686デフォルトの名無しさん

2007/06/10(日) 23:44:56

http://www.google.co.jp/search?q=%E3%82%AF%E3%82%AF%E3%83%AC%E3%82%AB%E3%83%AC%E3%83%BC
http://www.google.co.jp/search?q=%E3%83%9C%E3%83%B3%E3%82%AB%E3%83%AC%E3%83%BC
http://www.google.co.jp/search?q=%E4%B9%99%E3%82%AB%E3%83%AC%E3%83%BC

0687デフォルトの名無しさん

2007/06/11(月) 00:10:36

>>685
Amazon で売ってるよ。ククレはクックレスってホントかな…

0688デフォルトの名無しさん

2007/06/11(月) 00:18:50

アマゾンって・・・
日本ではもう売ってないの？

0689デフォルトの名無しさん

2007/06/11(月) 10:22:07

ttp://housefoods.jp/products/catalog/cat_1,1020,1059,1091.html
あるみたいだけど

0690デフォルトの名無しさん

2007/06/12(火) 21:41:04

グローバル変数ってもう安心して使えないのですか？
たとえばスレッドの終了フラグみたいな場合にグローバル
変数を使うのは危険なんでしょうか？
win32とlinuxを想定。

0691デフォルトの名無しさん

2007/06/12(火) 21:46:05

↑C言語を想定

0692デフォルトの名無しさん

2007/06/12(火) 22:07:51

pthreadのmutexやOSの排他機構を正しく使えばOK。
して久々にvolatile再来！？

0693デフォルトの名無しさん

2007/06/12(火) 22:13:39

つまり排他してないフラグで以下のようなスレッド
while(!sinu)
{
...
}
を実行していて、他のスレッドで
sinu=true
をしても、回りつづけてしまうことがあるんでしょうか？
最適化関連は捨象するとして。

0694デフォルトの名無しさん

2007/06/12(火) 22:20:22

ここを読めばスレッドにおける変数の扱いがよくわかるよ
ttp://d.hatena.ne.jp/yupo5656/20040618/p1

0695デフォルトの名無しさん

2007/06/12(火) 22:31:12

>マルチプロセッサ環境下で、あるプロセッサ上のスレッドが更新した変数の値が、別のスレッドで読めるかわからない
とのことなので、693は回りつづけることがあるということですね。

ところでpthread_mutex_lockやEnterCriticalSectionて
その内部コードのメモリアクセスに対して、実メモリにアクセスすることを
保証してくれるんですか？

0696デフォルトの名無しさん

2007/06/12(火) 22:38:16

＞とのことなので、693は回りつづけることがあるということですね。
それとも、値をセットした直後は回るかもしれないが、無限に
回ることはありえないってことなのでしょうか？

0697デフォルトの名無しさん

2007/06/12(火) 22:44:29

日本語でOK

0698デフォルトの名無しさん

2007/06/12(火) 22:58:29

これがわからないとこまるのでage

0699デフォルトの名無しさん

2007/06/12(火) 23:10:07

(ﾟдﾟ)ﾊｧ?
君の質問の答えはさっきのHPに全て書いてあるよ。
読んで解らないのなら基礎ができてないわけだから、pthreadの参考書買って一から勉強した方がいい。
少なくともスレッドプログラミングにおいては、基礎がしっかり理解できていないとまともなものは作れない。

0700デフォルトの名無しさん

2007/06/12(火) 23:11:49

>最適化関連は捨象するとして

ってなんで捨象しちゃうんだよﾌﾟﾝﾌﾟﾝ

0701デフォルトの名無しさん

2007/06/12(火) 23:12:53

>>699
書いてあるならここに書いて。
できないなら言い訳書いて。

0702デフォルトの名無しさん

2007/06/12(火) 23:17:57

大物のﾖｶﾝ

0703デフォルトの名無しさん

2007/06/12(火) 23:22:07

確かに大物っぽいなｗ

0704デフォルトの名無しさん

2007/06/12(火) 23:31:34

>>180辺りからの流れが再び

0705デフォルトの名無しさん

2007/06/12(火) 23:35:37

無能に限って態度がでかいなぁ

0706デフォルトの名無しさん

2007/06/12(火) 23:45:03

彼は切羽詰ってキレる寸前なんだよ

0707デフォルトの名無しさん

2007/06/12(火) 23:53:13

>>693
無問題
>>696
その通りだ

とりあえず何か問題出るようならまた聞いてくれ

0708デフォルトの名無しさん

2007/06/12(火) 23:59:44

>>707
ありがとう。安心しました。

>>705-706 m9（＾Д＾）

0709デフォルトの名無しさん

2007/06/13(水) 00:02:37

>>693
大問題
>>696
全然違う

とりあえず何か問題が出るようなら股に聞いてくれ

0710デフォルトの名無しさん

2007/06/13(水) 00:04:43

反応早すぎﾜﾛﾀ

0711デフォルトの名無しさん

2007/06/13(水) 00:07:41

>>693
排他していない限り環境依存であり断定できない
>>696
排他していない限り環境依存であり断定できない

とりあえず何か問題出るようならタマに聞いてくれ

0712デフォルトの名無しさん

2007/06/13(水) 00:12:20

>>708
お前の上げた例が単純だから
この例に限っては無問題でいいけどな。
ということを忘れるな。

0713デフォルトの名無しさん

2007/06/13(水) 00:12:30

C言語　スレッドあたりで検索すれば
レースコンディションの話なんて腐るほど出てくるだろうに・・

0714デフォルトの名無しさん

2007/06/13(水) 00:19:43

まあなんだ、普通はこれをレースコンディションの問題とは言わない

0715デフォルトの名無しさん

2007/06/13(水) 11:22:35

>>693
＞を実行していて、他のスレッドで
＞sinu=true
＞をしても、回りつづけてしまうことがあるんでしょうか？
大丈夫、電源落とせば確実に止まる。

＞最適化関連は捨象するとして。
「捨象」って意味わかっている? つーか、sinuの型も書かないで何を論じろと?

0716デフォルトの名無しさん

2007/06/13(水) 12:58:07

＞sinuの型も書かないで何を論じろと?
またか。
書いてること以外情報を補えないコンピュータ脳の持ち主。
trueって近くに書いてるのにbool型だと推測できないの？

0717デフォルトの名無しさん

2007/06/13(水) 14:50:48

そんな型はありません

0718デフォルトの名無しさん

2007/06/13(水) 15:25:49

>>716
最適化を捨象しちゃう香具師が、何を想定しているかなんて推測不可能だ。
それに、Cならtrueがbool型である保証がないのでなんでもありだしね。
#C++なら演算子オーバロードでやっぱりなんでもありだけど。

0719デフォルトの名無しさん

2007/06/13(水) 16:01:08

こんなところに書く例でオーバーロードとか別に深読みする必要もないし。
C言語だからboolが無いってのに突っ込むのも今更。

0720デフォルトの名無しさん

2007/06/13(水) 16:20:36

本人必死過ぎ

0721デフォルトの名無しさん

2007/06/13(水) 17:02:17

704のレスをみて180あたりから目を通してみたのですが、volatile論争はともかく
mutexロック自身のコストはそんなに高いものなんでしょうか？

多数のスレッドがmutexロックを掛けたリソースにアクセスする場合のロック取得の為の待ち時間が発生するのは理解
できるのですが、仮定として1スレッドしか無い場合(つまり他のスレッドとのロック取り合戦が発生しない場合)の
コストがどんなものなのか知りたいです。

0722デフォルトの名無しさん

2007/06/13(水) 18:38:31

裏でビデオのエンコードをやってる環境なので
相当イイカゲンなテストになっちゃったんだけど…。
Win32のCriticalSectionとMutexについて、
取得と開放のループをシングルスレッドで100万回ずつ回してみた。

CriticalSectionの 32ms に対して、Mutexは 960ms。
思ってたより差があるなぁ。

0723デフォルトの名無しさん

2007/06/13(水) 18:52:39

mutexは普通カーネルモードへの遷移が要るからなのかな？

0724デフォルトの名無しさん

2007/06/13(水) 18:55:06

およそ1マイクロ秒か、確かにかなり重いな…

0725デフォルトの名無しさん

2007/06/13(水) 19:10:14

linuxはCriticalSection相当は無いの？　もしくはlinuxのmutex
はすごく軽いとか。

0726デフォルトの名無しさん

2007/06/13(水) 19:27:00

いまLinuxで100満開mutexロック～解放やってみたけど0.178秒だった(boost::thread使った)
ちなみにAthron2400なマシンでKernel2.6(NPTL)

0727デフォルトの名無しさん

2007/06/13(水) 19:42:16

721で言っているmutexってのは
Win32ではCriticalSectionにあたる機構だし、
721の疑問に対するWin32環境での答えは、
CriticalSectionの100万回32msのほうだね。
(報告上げといて今更だけど…すまん)

0728デフォルトの名無しさん

2007/06/13(水) 20:10:40

Win32のCRITICAL_SECTIONは(内部でどう工夫してるかは知らないが)
(PC-Unix系の)pthread_mutexよりかなり速いという話は聞いたことがある。

スピンロックをできるだけ高速で取得する工夫をしていて、
もしかしたら関数呼び出しを抑えてるのかも。
当然、どちらもロックをダイレクトに獲得できるときはカーネルに移行しないはずだけど。

0729デフォルトの名無しさん

2007/06/13(水) 20:13:55

で、ロックのコストだが、処理によっては確かに気になる場合もある。
例えば、少し前に別スレで「VC++のfputcが遅い」という話があった。
これは、一文字出力する度にロックしているため。
(最近のVC++はMTライブラリしか提供していない)

もちろん、こんなのは工夫次第でなんとでもなるのだが
知らないと悩むことにもなりかねない。

0730デフォルトの名無しさん

2007/06/13(水) 20:41:41

Win32のクリティカルセクションは競合が発生してない限り
カーネルに遷移しないから高速なんじゃなかったっけ
スピンロックか何かしてたような

0731デフォルトの名無しさん

2007/06/13(水) 21:27:44

僕にはついていけない・・

0732デフォルトの名無しさん

2007/06/13(水) 21:36:37

速さなんて相対的なもんだ
何かとの比較なしに語ったところで意味が無い

関数呼び出しは、速いか？　みたいなもんだな
関数呼び出しのオーバーヘッドが気になるようなケースもあるからinline関数の
ようなものが存在する
ロックもしかりだよ

0733デフォルトの名無しさん

2007/06/13(水) 21:48:44

Win32のクリティカルセクションが速いのは、InterlockedExchangePointerを
使っているからだよ。
これは、アトミックな処理で値を交換するAPI。もちろんユーザモードのまま。

0734 ◆0uxK91AxII

2007/06/13(水) 22:26:44

>>728
mutex objectはhandleを用いる。
コレに触れる事は、kernel objectを操作する事を意味する。

0735デフォルトの名無しさん

2007/06/13(水) 22:28:55

>>732
だからCRITICAL_SECTIONとMutexやpthread_mutex_tとの比較の話だろ？

もしかして、あなたには見えないの？

0736デフォルトの名無しさん

2007/06/13(水) 22:34:31

>>734
え、毎回カーネルに行っちゃうの？
「スピンロックが取れないときだけ」カーネルに移行すると思ってたけど。
(当然、スピンロックはlock+cmpxchg+pauseを使って)
だったら、差がついても仕方ないとは思うけど。

カーネルで作成するものだとしても、ユーザー空間に必要な部分だけをマップして
読み取り(必要なら読み書き)可能にしてるものって、結構あるでしょ？時刻とか。
いや、ソース見ないで想像で書いてるだけだから、違ったらごめんね。

0737デフォルトの名無しさん

2007/06/13(水) 23:10:42

100万回で1秒が遅いって、オマエら普段どーいうプログラム作ってる
んだよ。1秒間に何回同期してるのか気になる。1万回超えたら特殊領域じゃね？
それともI/Oが0.001秒かかるところが同期によって0.001001秒に
なったから遅いとか言ってるんじゃねーだろーな。

0738デフォルトの名無しさん

2007/06/13(水) 23:19:42

わずか1000回で1msもかかる処理は、出来れば呼び出しを減らしたいと俺は思うね。

0739デフォルトの名無しさん

2007/06/13(水) 23:33:37

で、発端の>>693みたいな、
メモリの参照するだけなのに1ms/1000回もの時間をとられちゃかなわないから
なんとかvolatileだけで済ませないかという話も出てくるわけだな。

まあ実際には(スレッド間のロックは)もっとずっと短時間だからいいけど。

0740デフォルトの名無しさん

2007/06/13(水) 23:36:59

>>737
getc()/putc()の類は、古典的なマクロ版ではほぼ単純なポインタ操作だけ・
マルチスレッド対応版は、これに関数呼び出しやロック等、もろもろの
オーバーヘッドが加わる。

この場合、ロックだけがオーバーヘッドじゃないわけだが、
0.001秒が0.001001秒なんてモンじゃない、確実に数倍以上は違うよ。
VS2003以前の環境を持っているなら、計測してみればよい。

0741デフォルトの名無しさん

2007/06/13(水) 23:40:43

>>736
> え、毎回カーネルに行っちゃうの？

mutex は他プロセス(not スレッド)との同期も取るからな。

0742デフォルトの名無しさん

2007/06/13(水) 23:52:34

確かにCygwinのfputcは無駄に遅い。

0743デフォルトの名無しさん

2007/06/13(水) 23:53:07

>>741
おいおい、pthreadのmutexだよ？

0744デフォルトの名無しさん

2007/06/13(水) 23:54:51

どう考えても話の流れからしてWindowsのMutexの事じゃないか

0745デフォルトの名無しさん

2007/06/13(水) 23:55:17

初心者ですみませんが教えてください。

gethostbyname( ) のようなスレッドセーフでないライブラリ関数にはなにがあるのか、
リストみたいなものはあるんでしょうか？
また自身で作成する関数は別として、上の様な関数をマルチスレッドで使っても
気にしなくてすむ良い方法はないでしょうか？
セマフォを掛けるにしても、その関数が内部でstatic変数を使用しているか分からないとダメですよね。

よろしくお願いします。 m(_ _)m

0746デフォルトの名無しさん

2007/06/13(水) 23:58:17

>>744
どう見ても>>728からの流れで、pthread_mutexとの比較ですけど？

0747746

2007/06/14(木) 00:00:19

>>744
>>728 >>734 >>736 >>741と見てくださいね。

0748デフォルトの名無しさん

2007/06/14(木) 00:07:22

mutexと書かれるとLinux
Mutexと書かれるとWin32を前提として
話を読み進めてしまう自分がいることに気が付いた。
チラ裏

0749デフォルトの名無しさん

2007/06/14(木) 00:11:45

俺も基本的には同じよん

0750デフォルトの名無しさん

2007/06/14(木) 00:13:59

>>748
今後はそれで行こう

次スレのテンプレに入れといて。

「別途断りの無い場合は mutex は pthread、Mutex は Windows と見なします」

0751 ◆0uxK91AxII

2007/06/14(木) 00:54:54

>>734の内容は、728ではなく、>>723への書込みだと訂正しておく。

#3と8は見た目が似ているから、打ち間違えやすい(ぉ

0752デフォルトの名無しさん

2007/06/14(木) 22:00:53

スレ違いかもしれんけど
デュアルコアのＣＰＵの場合
子プロセスや孫プロセスをたくさん
起動した場合、ちゃんとコアは
振り分けられるの？
それとも片方のコアだけ使うの？

0753デフォルトの名無しさん

2007/06/14(木) 22:12:33

>>752
まともなスケジューラを持った OS ならきちんと振り分けられる。
大抵の OS なら自分で振り分ける事も可能な筈だ。
もちろん片方のコアだけを使うようにも設定出来る。

0754デフォルトの名無しさん

2007/06/14(木) 23:33:04

それはよかった

0755デフォルトの名無しさん

2007/06/16(土) 12:12:42

>>745
ttp://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
2.9.1 Thread-Safetyの項
あとはライブラリのマニュアルを読む

0756デフォルトの名無しさん

2007/06/19(火) 22:20:52

このスレは今後重要になる。
今のプログラムをマルチスレッドにコンパイルするだけでなく、
プログラムをマルチスレッドに書き換えるソフトってないんかな・・・

ええ、マルチスレッドのことはあまり知りませんとも。

0757デフォルトの名無しさん

2007/06/19(火) 22:39:26

>>756
既存プログラムの実行形態を変更するって事?
(基本的に)無理。

0758デフォルトの名無しさん

2007/06/20(水) 00:47:32

>>756
ベクトルプロセッサとかで

for (int i = 0; i < N; ++i) {
　array[i] = func(i);
}

みたいな時に i 毎に振り分ける処理系はあったと記憶してる。
だけど func() が array[] その他の i について
依存してないことを検出するか手動で指定する必要がある。
…二十年位前の知識だから今はもっと進んでるかもだけど。

効率を求めればそういうアルゴリズムを駆使することになるし
設計から考えないといけないので自動化のうま味はあまり無いと思う。

最近その辺の動的自動化の研究を理研とかNECとか日立辺りが組んでやろうぜっていう話が
あるらしいけどな。

0759デフォルトの名無しさん

2007/06/20(水) 01:00:48

http://pc11.2ch.net/test/read.cgi/tech/1137540671/370-
みたいな話かね。

10年程度で実用になるものが出ればすごいとは思うけど。

0760デフォルトの名無しさん

2007/06/20(水) 02:46:17

>>758-759
>756はそういう話なの?

＞今のプログラムをマルチスレッドにコンパイルするだけでなく、
＞プログラムをマルチスレッドに書き換えるソフトってないんかな・・・

「コンパイル」じゃなく「書き換える」そうなのだけど。

0761デフォルトの名無しさん

2007/06/20(水) 03:24:52

JIT っぽいのが研究されてる希ガス

0762デフォルトの名無しさん

2007/06/20(水) 06:42:01

>>758
そっち系はHDLで

0763デフォルトの名無しさん

2007/06/21(木) 00:53:59

Javaにつかりすぎてガベコレのない言語では書きたくなくなった俺が
通りますよ。
Javaはスレッド使いやすくていいな。C#はまだ勉強中。

0764デフォルトの名無しさん

2007/06/21(木) 00:57:12

GC のある言語はスケールし辛いのが難点だね。
Java はかなり頑張ってると思うけど。

0765デフォルトの名無しさん

2007/06/21(木) 05:34:03

涼宮ハルヒも分裂ぎみだな

ああいうの書いてて恥ずかしくないんかな

0766デフォルトの名無しさん

2007/06/21(木) 12:04:36

javaや.netの中間言語形式から
並列成分を抜き出して以下略とかいうのはないかな

やっぱ開発者がアノテーションしないと無理か

0767デフォルトの名無しさん

2007/06/21(木) 19:15:42

.netってやったこと無いが、なぜバイトコード形式のアーキテクチャーにしたんだ。
Windows以外のプラットフォームにも移植する計画があったのだろうか？
公式ではWindows以外のかんきょ

書いててふとスレ違いだと気づいた。

0768デフォルトの名無しさん

2007/06/21(木) 19:59:09

>>767
当時は、次の 10 年も x86 が支配するとは確定してなかったからね。
実際はサーバからデスクトップ、モバイルまで x86 で大体いいやという
世界になりつつあるけど。バイトコードならどの CPU が支配的になっても
良いし、セグメント毎に違う CPU が勝ち残っても問題が少ない。
それと、同じ x86 でも CPU 毎にキャッシュのサイズやら何やらが変わる
から、それぞれに JIT で後付けの最適化が出来るのは嬉しいでしょう。

あと、Windows 以外は考えてないと思うな。昔で言う NT 系みたいな、
別の Windows の登場は考えていたかもしれないけど。

0769デフォルトの名無しさん

2007/06/21(木) 23:12:30

X64やらIA64やらX86やらにネイティブに対応するにはどうする？
ってだけで現実に意味あるだろう。

0770デフォルトの名無しさん

2007/06/21(木) 23:14:06

あーネイティブってのは、えーと、んんんややこしいな、なんか誤解を生みそうだ…

0771デフォルトの名無しさん

2007/06/22(金) 21:27:41

このスレって相変わらずスレ違い発言多いなぁ

0772デフォルトの名無しさん

2007/06/23(土) 07:51:10

pthreadでマルチスレってる人たちに伺いたいのだが、
デバッグのツールとかでオススメはない？

0773デフォルトの名無しさん

2007/06/23(土) 09:59:31

>>772
スレ違い

0774デフォルトの名無しさん

2007/06/23(土) 14:49:53

>>773
いや全然スレ違いじゃないだろ。。

0775デフォルトの名無しさん

2007/06/23(土) 17:48:55

ここらへんでダンゴさんのシメのレスが欲しいところだ

0776デフォルトの名無しさん

2007/06/23(土) 19:44:28

団子ﾁｭｰさーん

0777デフォルトの名無しさん

2007/06/28(木) 21:42:28

LOOP処理を自動で分解してくれるjavaのライブラリないかね？

0778デフォルトの名無しさん

2007/06/28(木) 21:56:54

>>734
遅レスだが、とりあえず、バル、バル、バルル ...と効果音を入れておこう。

0779デフォルトの名無しさん

2007/06/28(木) 22:09:33

SoftwareTransactionMemoryについて詳しいサイトないかのう・・・

0780デフォルトの名無しさん

2007/06/28(木) 22:27:26

なぜハンドルがあるのにサドルやペダルはないんでんしか？

0781デフォルトの名無しさん

2007/06/28(木) 22:30:33

昔はあったんだけど技術の進歩とともに廃れたいいった
例えると、人間が漕がなくても進む自転車ができたようなもの。

0782デフォルトの名無しさん

2007/06/28(木) 22:31:37

たとえ漕がずに済んでもサドルはいるべ
すわれねーじゃんｗ

0783デフォルトの名無しさん

2007/06/28(木) 22:34:19

サドルがなくても坐れる自転車もできたようなもの。

0784デフォルトの名無しさん

2007/06/28(木) 22:36:35

そのうちハンドルもいらなくなるんじゃね？

0785デフォルトの名無しさん

2007/06/28(木) 22:40:00

>>782
ネタにまじレス香代

0786デフォルトの名無しさん

2007/06/28(木) 22:42:09

> 香代
どこで売ってますか？

0787香代

2007/06/28(木) 22:48:01

持ってますよ
お譲りします？

0788デフォルトの名無しさん

2007/06/28(木) 22:49:46

香代より田代の方が良いです...

0789デフォルトの名無しさん

2007/06/29(金) 12:47:01

OpenMPはJavaでは使えないのでしょうか？？

0790779

2007/06/29(金) 20:22:32

フォォォォォォー

0791香代

2007/06/29(金) 20:50:52

そんなん知らないもん

0792779

2007/06/29(金) 22:37:28

あった
http://www.dodgson.org/omo/t/?date=20070623

DBのトランザクションのメモリ版？
従来のロック替わりにTransactionMemoryを使う
指定区間が終わるタイミングでメモリの内容をコミットする
コミットは自動で行われる
コミットに失敗したトランザクションは再実行される

という理解でいいんだろうか

0793デフォルトの名無しさん

2007/06/30(土) 00:14:23

どこぞのスレで
＞サーバ落ちた。 SQL流すなよ
みたいなのを見たが、複雑なシステムだったりWEBがらみだったりして、
でかいSQLが来ることがありうるなら、オープンコボルなんかありじゃないかな。
SQLは前処理・後処理(トリガ。選択の余地無しで必ず掛かる)、カスタマイズが苦手。
その点コボルなら
クライアント⇔ＣＯＢＯＬ⇔ＤＢ
　(CALLインターフェース)(CALLインターフェース)
で通常SQLの部分が柔軟性のあるプログラムになる。
更に、SQLでいうストアド呼び出し、逆ストアドみたいなこともできる
ＣＯＢＯＬ→Ｃ言語(CALL)、Ｃ言語→ＣＯＢＯＬ(関数)
オープンコボルだとＪＡＶＡも使えるらしい。
トランザクションは
http://jp.bea.com/e-docs/tuxedo/docs71j/html/rf3cbl2.htm
みたいなのが検索したらヒットした。要はＴＰモニタの型を使ってカスタマイズするようなものか(ＴＰモニタインターフェース)
ＳＱＬの手狭感がぬぐえない場合、そろそろＣＯＢＯＬも見直されてもいいんじゃないかな。

0794デフォルトの名無しさん

2007/06/30(土) 02:02:38

どこの誤爆ですか

0795デフォルトの名無しさん

2007/06/30(土) 15:34:58

質問です。マルチスッドレの説明がしてある場面では必ずスレッドセーフうんぬんと
いきなり話が始まりますが、その前提が説明されていることが少ないですよね。
スレッドセーフを意識しなければいけないのはオブジェクトのインスタンスがシングルトン
な場合やインスタンスがスレッド間で共有されている場合だけですよね？
逆に言えばそうでない場合、シングルトンなオブジェクトもなく、スレッド毎にインスタンス
を作成して並行に処理するだけなら不要ってことでいいでしょうか。
前提がきちんと書かれていないことが多いもので質問しました。

0796デフォルトの名無しさん

2007/06/30(土) 15:37:48

共有部分がまったくないならマルチプロセスと見分けが付かない

0797デフォルトの名無しさん

2007/06/30(土) 18:33:03

シングルトンなオブジェクトにハードウェアリソースを含めるならそうかもしれないね

0798デフォルトの名無しさん

2007/06/30(土) 18:33:29

↑意味不明w

0799デフォルトの名無しさん

2007/06/30(土) 18:34:14

あ、>>796がね

0800795

2007/06/30(土) 19:18:13

>>797
確かに。例えば一括印刷などの処理で対象処理が処理1～5とか複数あった場合に
上から順番に流していくより、それぞれ単独スレッドで実行した方が昨今のマルチコア
環境を有効に使えるんではといった感じです。この場合処理間に横の関係はありません。
（間に別の帳票が挟まってしまうじゃないか！というのは本題ではないのでとりあえず
おいて置いてください）
もちろんファイルIOやDB書き込みなどのバッティングが無い処理でオブジェクト内で利用する
サードパーティ製等のオブジェクトがスレッドセーフかどうかは調べがついている、という前提です。
こうした場合、自作クラスではロックなどのスレッドセーフは考慮する必要はないのではないか？
というのが言いたいことでした。

0801デフォルトの名無しさん

2007/06/30(土) 20:19:00

複数ロックがあると獲得順番によってデッドロックが起こりうるが
そのレベルの考慮は自前でやるとして？

0802デフォルトの名無しさん

2007/06/30(土) 20:31:57

それはスレッドセーフにするための考慮をしたうえで、
ロックなどを用いなくても大丈夫と判断したんじゃないのか？
ロックなどを用いなくてもスレッドセーフである、というだけだろ。

0803デフォルトの名無しさん

2007/06/30(土) 20:36:24

「スレッドセーフを考慮」がいい味出してるな

0804デフォルトの名無しさん

2007/06/30(土) 21:24:37

>>795
人に質問をするときは、ちゃんと質問内容を整理してから書けよ・・・

Q1. >>795 の云う「考慮」って一体どういう事？
自分の書くソースの中で排他処理を書くか・書かないか？ってこと？
それとももっと一般的な話？

Q2. >>795 は一体何のためにスレッドを使いたいの？
>それぞれ単独スレッドで実行した方が昨今のマルチコア
>環境を有効に使えるんではといった感じです。
って事は、もしかしてただ単純に、
複数プロセッサを同時に動かして速くしたいだけなの？

0805デフォルトの名無しさん

2007/06/30(土) 22:07:54

スレッドを複数用意してアプリケーションの中で発生するタスクに対して
リソースのようにして割り当てて使う方法ってなんか呼び方ありますか？

0806795

2007/06/30(土) 22:19:41

>>804
すいませんです。。

> Q1. >>795 の云う「考慮」って一体どういう事？
> 自分の書くソースの中で排他処理を書くか・書かないか？ってこと？
> それとももっと一般的な話？

両方になるかもです。自分の書くソースもそうですが、一般的にあるオブジェクトの
インスタンスを共有しない場合はロック処理は必要ないのでは？という疑問です。
なぜ疑問なのかというとロック処理が必要な条件が明記していない記述が多く、
ひょっとしたら言語によっては異なるインスタンスでもクラスが同一ならマルチスレッド下
ではインスタンスメンバ等が共有される（メモリ節約の都合上とか）仕様とかがあって
マルチスレッドではロックが前提とかあるのかな？と思いました。

> Q2. >>795 は一体何のためにスレッドを使いたいの？
（中略）
> 複数プロセッサを同時に動かして速くしたいだけなの？

そうなります。バックグラウンドで処理とか処理中UIを操作させるためとか今の所
考えていません。直列で動かす必要のない処理を処理時間が短くなれば自分
的には充分です。

質問しといてあれなのですが、ちょっと今からパソコンが使えなくなるのでまた明日
見に来ます。すいません。

0807デフォルトの名無しさん

2007/07/01(日) 00:33:53

＞ロック処理が必要な条件が明記していない記述が多く、
ほとんどは、共有リソースにアクセスする場合、とか少なくともそういう書き方してるように思うが。

0808デフォルトの名無しさん

2007/07/01(日) 01:35:32

「スレッド間で共有されないインスタンスは
　ロックせずに読み書きしても問題ないと思うのですが、
　それでもロックが必要になるケースというのはあるのでしょうか？」

ずいぶん長ったらしく書いてくれたけど、つまりこういうことだろ？

0809デフォルトの名無しさん

2007/07/01(日) 01:47:59

本当に共有している部分がないならいらないだろ。

0810デフォルトの名無しさん

2007/07/01(日) 02:32:32

排他処理が不要というとこんなケースかな。
スレッドを生成する前に必要なデータを共有する変数にセット。
スレッド生成、処理開始。この間共有する変数は生成したスレッドからだけアクセス。
処理終了とJoin。その後共有する変数から結果を取得。
実際はスレッドの生成時と終了/Join時にメモリバリアが存在しているのだろうけど。

0811デフォルトの名無しさん

2007/07/01(日) 02:33:40

>>810
紛らわしいのでちょっと訂正
×生成したスレッド
○生成されたスレッド

0812デフォルトの名無しさん

2007/07/01(日) 10:54:09

スレッド生成(or Join時)に、親スレッドが書いたデータを、明示的な
メモリバリアなしにサブスレッドが読み出せることって保証されてるんかね？
pthreadは保証されてるみたいだけど、Win32 APIとかどこかに書いてある？

0813デフォルトの名無しさん

2007/07/01(日) 11:24:00

pthreadが保証しているというソースキボン

0814795

2007/07/01(日) 19:50:29

>>807-811
どうもです。説明が下手ですいません。
共有がないならロック処理はいらなさげということで安心しました。
ただ、自作クラスから使用する各言語の標準クラス等について共有メンバがないか継承元の
基本クラスレベルまで調べるのが手間ではありますが・・
大抵はインスタンスメンバはスレッドセーフではありませんとかそっけなく書いてあるだけなので・・
こいいう場合はロック処理を書いたラップクラスで包んであげてスレッドセーフにするのが定石
なんでしょうかね。

0815デフォルトの名無しさん

2007/07/01(日) 21:23:49

んなのインスタンス自身を共有してなければ安全とみなすしかないだろう。
そうでなければそれはライブラリの実装の問題だ。

0816デフォルトの名無しさん

2007/07/02(月) 00:37:15

>>813
こんなのでいい？
http://www.cs.tsukuba.ac.jp/~yas/sie/pdsoft-2001/2002-01-17/
　→　「◆Pthreadのメモリモデル」

0817デフォルトの名無しさん

2007/07/02(月) 22:48:54

そういえば、Windowsのメモリモデルのドキュメントというのは見たことないのですが
どこかにありますか？
Windows2003のPlatform SDKからMemoryBarrierマクロというのが増えていますし、
その辺で何か変わっているはずなのですが。

0818デフォルトの名無しさん

2007/07/02(月) 23:21:05

>>805
スレッドプーリング (Thread Pooling)

0819デフォルトの名無しさん

2007/07/02(月) 23:24:24

.NETですが質問させてください。
次のようなクラスがあります。

public class BackgroundWorker: Componet {
　private bool cancellationPending;
　public bool CancellationPending {get {return cancellationPending;}}
　public void CancelAsync {
　　　cancellationPending = true;
　}
　．．．
}

ワーカースレッドでCancellationPendingを調べて止めるという使い方なのですが、
排他は必要ないんでしょうか？

0820デフォルトの名無しさん

2007/07/02(月) 23:30:00

volatile 指定して、ついでにThread.MemoryBarrier() も呼んでやらないと
IA64 の SMP とかで困ることになることがあるかもしれない。

0821デフォルトの名無しさん

2007/07/02(月) 23:42:35

>>820
やはりそうですか。
Reflectorで
System.ComponentModel.BackgroundWorkerの実装を見て、悩んでいました。

Microsoftが実装しているのに、残念です。

0822デフォルトの名無しさん

2007/07/02(月) 23:46:46

cancel してから calcel されるまでの時間が不定で構わない、
という仕様なら、実運用で問題は起きなそうな感じ・・・

0823デフォルトの名無しさん

2007/07/03(火) 01:14:37

BackgroundWorkerはComponent派生
ComponentはMarshalByRef派生
MarshalByRefのメソッド呼び出しはインライン展開されない
分かったか？

0824デフォルトの名無しさん

2007/07/03(火) 01:15:41

＞volatile 指定して、ついでにThread.MemoryBarrier() も呼んでやらないと
どんな意味ないvolatileだよｗ

0825デフォルトの名無しさん

2007/07/03(火) 01:42:33

いろいろ理屈があってこうなってるのだろうけど、
自分でやるときはlockかvolatileを使ったほうが無難だろうな。

0826デフォルトの名無しさん

2007/07/03(火) 01:49:38

>>824
volatile は VM やコンパイラに対する指示で、メモリバリアとは別のもの。

0827デフォルトの名無しさん

2007/07/03(火) 02:04:57

はいはいCLIの仕様を理解してから言おうね。

0828デフォルトの名無しさん

2007/07/03(火) 02:47:18

>>825
それは同意。
自信がないならlockしとけってな。

0829デフォルトの名無しさん

2007/07/03(火) 07:26:48

>826
C#のvolatileはメモリバリアも行う。

0830デフォルトの名無しさん

2007/07/04(水) 00:27:28

lockを使うけどおかしな使い方するやつはどうしてくれたらいいですか？

0831デフォルトの名無しさん

2007/07/04(水) 06:48:45

Lock! Lock! the L.M.C!

0832デフォルトの名無しさん

2007/07/07(土) 11:36:38

struct pointer_t {
<ptr, tag>: <node_t *, unsigned integer>
};
struct node_t {
data_type value;
pointer_t next;
pointer_t prev;
｝
struct queue_t {
pointer_t tail;
pointer_t head;
}

void enqueue(queue_t* q, data_type val)
{
pointer_t tail
node_t* nd = new_node()
nd->value = val
while(TRUE){
tail = q->tail # Read the tail
nd->next = <tail.ptr, tail.tag+1>
if CAS(&(q->tail), tail, <nd, tail.tag+1>){
(tail.ptr)->prev = <nd, tail.tag>
break
}
}
}
これって本当にLock-Free FIFOなの？
というかLock-Free系のアルゴリズムの解説されている書籍ない？
いちいち論文探して読むのすっごい面倒なの

0833デフォルトの名無しさん

2007/07/07(土) 12:02:29

http://www-06.ibm.com/jp/developerworks/java/060519/j_j-jtp04186.shtml
これじゃなくて？

0834デフォルトの名無しさん

2007/07/07(土) 12:06:16

>>833
ふむふむ、できればJAVAとかエセ言語じゃなくて
CとかC++の解説が乗ってるの知りませんか？

0835デフォルトの名無しさん

2007/07/07(土) 12:12:42

言語に依存した話題でも無いのにw

0836デフォルトの名無しさん

2007/07/07(土) 13:04:09

毎回コンパイルする際に、-lpthreadをつけているのですが、環境変数か何かを使って
これを省略する方法はないでしょうか？

0837デフォルトの名無しさん

2007/07/07(土) 13:05:26

あります

0838デフォルトの名無しさん

2007/07/07(土) 13:10:25

>>836
mekfike

0839デフォルトの名無しさん

2007/07/07(土) 13:10:40

>>836
いくらくれる？

0840デフォルトの名無しさん

2007/07/07(土) 13:12:43

>>836
alias tcc='cc -lpthread'

0841デフォルトの名無しさん

2007/07/07(土) 20:36:34

全然これわからねーYO

http://www.cs.brown.edu/people/mph/DohertyHLM04/ft_gateway.cfm.pdf

0842デフォルトの名無しさん

2007/07/07(土) 21:02:34

だれか助けてくれYO

0843デフォルトの名無しさん

2007/07/07(土) 21:11:00

何がわからんのよ CAS？

0844デフォルトの名無しさん

2007/07/07(土) 21:15:59

>>843
CASは解かるけど、後のアルゴリズムがなんで
ここでCAS使うとlock-freeになるのか解からん。

というかlock-freeってパフォーマンス本当にいいの？

0845デフォルトの名無しさん

2007/07/07(土) 23:51:55

volatileには勝てないと思う

0846デフォルトの名無しさん

2007/07/08(日) 16:52:13

おまいら教えてくれ。スレッド(pthread)の死活管理ってどうやるのがよい？
突然スレッドの一つが死んでいてアプリの動きに異常をきたしていた
スレッドの死んだ原因はわかったけど原因究明に多大な時間を浪費したし
今後も似たような問題が起こらないとも限らないので解決策を求めています

現在動いているスレッド一覧をアプリから取得するコマンドとかないっすかねぇ
スレッドには初めて挑戦するが思った以上に難しいな・・・

0847デフォルトの名無しさん

2007/07/08(日) 17:12:07

WDT

0848デフォルトの名無しさん

2007/07/09(月) 01:58:16

カーネルスレッド単位なら、psとかにそういうオプションありそうだけど。
ユーザスレッドだと外部からは見えないんだからいかんともならん。

0849デフォルトの名無しさん

2007/07/09(月) 23:01:41

>>846糞コード投下します。Linux限定でpthread_getattr_np()が
０以外ならスレッドしんでます。だから、デバッグ用アプリなんか作成して
共有メモリかなんかにpthread_tとpthead_attrを公開してやってpthread_getattr_np()すれば解かるよ
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
void * TestThread1(void *arg){
sleep(3);return NULL;
}
void * TestThread2(void *arg){
sleep(5);return NULL;
}
int main(){
int ret1 = 0, ret2 = 0;
pthread_t pt1, pt2;
pthread_attr_t attr1, attr2;
pthread_create(&pt1, NULL, TestThread1, (void *)NULL);
pthread_create(&pt2, NULL, TestThread2, (void *)NULL);
while(1){
ret1 = pthread_getattr_np(pt1, &attr1);
ret2 = pthread_getattr_np(pt2, &attr2);
if( ret1 > 0 && ret2 > 0){
fprintf(stdout, "[RET1 %d] [RET2 %d] thread term\n",ret1, ret2);
return 0;
}
fprintf(stdout, "[RET1 %d] [RET2 %d]\n",ret1, ret2);
pthread_join(pt1, NULL);
pthread_join(pt2, NULL);
}
return 0;
}

0850846

2007/07/10(火) 01:33:00

>>849
うぉおお！これだ！
情報ありがとうございます。明日にでもいろいろ試してみます

でもpthread_getattr_np()のmanがないのが気になる・・・
どこかに戻り値の説明がないでしょうか？

0851デフォルトの名無しさん

2007/07/10(火) 10:39:19

ソースがあるじゃないか

0852デフォルトの名無しさん

2007/07/14(土) 11:38:27

スタックの代わりになる
マルチスレッド処理向けのデータ構造って有りますか?

0853デフォルトの名無しさん

2007/07/14(土) 12:09:46

>>852

４CPU12スレッド以上ならこの辺みて必要な
アルゴリズム実装しろ。単純なデータのやりとりなら
従来のロック機構＋共有メモリ配置で対処しろ

http://www.audiomulch.com/~rossb/code/lockfree/

0854デフォルトの名無しさん

2007/07/14(土) 13:28:12

意味がわかりません><

0855デフォルトの名無しさん

2007/07/14(土) 13:31:44

習志野う

0856デフォルトの名無しさん

2007/07/14(土) 17:54:52

スタックの代わりの意味がわからん
TLSじゃだめなのか

0857デフォルトの名無しさん

2007/07/16(月) 01:01:54

lock-free または wait-free なデータ構造を考えてるんですが
Exchangeがアトミックな関数だとして、関数Popは
スレッドセーフでしょうか？
first->nextを読み出してる間にfirstが書き換えられる恐れがありますか？

typedef struct Node{
Node* next;
int value;
}
Node* first;

int Pop(){
Node* n = Exchange(first, first->next);
return n->value;
}

0858デフォルトの名無しさん

2007/07/16(月) 01:05:00

>>857
そんな微妙な話なら特に、ちゃんとコンパイルできるコード貼れ。

0859デフォルトの名無しさん

2007/07/16(月) 12:08:17

>>857
> first->nextを読み出してる間にfirstが書き換えられる恐れがありますか？
当然ある。
だから、こういう状況では compare-and-swap (CAS) を使うのが定石。

0860デフォルトの名無しさん

2007/07/17(火) 00:06:52

>>859
当然ってのはどういうこと？グローバル変数だから？
だったら CAS 使っても問題が解決しないよね？

0861デフォルトの名無しさん

2007/07/17(火) 00:26:02

CASで成功するまで繰り返し

0862デフォルトの名無しさん

2007/07/17(火) 00:37:24

というか、そのあたりが判らないなら、Lock-freeな
アルゴリズムを実装するのは止めといた方が良い

0863デフォルトの名無しさん

2007/07/17(火) 01:44:11

>>860
その前に問題は分かったのか

0864デフォルトの名無しさん

2007/07/17(火) 06:33:10

>693のお馬鹿ちゃんと同じ匂いがするな

0865デフォルトの名無しさん

2007/07/26(木) 22:36:34

winsockでＵＤＰのサーバプログラムを作ってるんですが、どうすればスレッド化できるのかがわかりません。
ログインを済ませたらユーザー毎にスレッドを立ち上げ、一度ログインした人からはそのスレッド内でコマンドを受けるようにしたいのです。

0866デフォルトの名無しさん

2007/07/26(木) 22:40:45

待ち受けポートが同じなら、デマルチプレキサを実装して、
スレッドに分配してあげたら。

0867デフォルトの名無しさん

2007/07/26(木) 22:47:51

>>866
デマルチプレキサって何ですか？

0868デフォルトの名無しさん

2007/07/26(木) 22:52:32

multiplexerの反語じゃないのか？
マルチプレクサってよまね？

シナが>>867同じ撥音で言うから俺はすげー
そのいいかたするやつ心んでほしいと思う

0869デフォルトの名無しさん

2007/07/26(木) 22:52:32

セレクタのことだろ

0870デフォルトの名無しさん

2007/07/26(木) 23:03:21

特にユーザー・スレッド間に関係がなくて、(Inpersonationとか)
単にコマンドを並列実行したいだけなら、複数スレッドでrecvfrom
でコマンドが来るまで待ってる、という選択肢もあるはず。

0871デフォルトの名無しさん

2007/07/27(金) 14:08:04

>>865
スレッド毎にキューを作る。
メインのスレッドは recvfrom で受信し、送り側IP:ポートの組で既存のスレッドを探し（なければ作る）、
そのスレッドのキューに受信したメッセージを追加し、スレッドを待機状態から実行状態へと遷移させる。
スレッド側はキューにメッセージがあれば処理し、なければ待機する。

0872デフォルトの名無しさん

2007/07/27(金) 14:40:59

すいません。Ｃ言語の初心者なんですが、作り方がわからないプログラムがあります。
初めに数字を入れて、次に+、-、*、/、＝と聞かれ、＝が押されるまで計算を繰り返
し、＝が押されると合計＝結果と出したいのですがどなたか教えていただけませんか
？

0873デフォルトの名無しさん

2007/07/27(金) 14:41:41

>872　すれ違い

0874デフォルトの名無しさん

2007/07/27(金) 23:38:11

複数のNICから時系列順に
非同期にパケットを受信する方法ってありますかね？

0875デフォルトの名無しさん

2007/07/28(土) 00:55:05

スレ違い？

0876デフォルトの名無しさん

2007/07/28(土) 02:55:33

>>872
宿題は宿題スレへどうぞ。

0877デフォルトの名無しさん

2007/07/31(火) 01:27:12

なんで, このスレ繁盛してんの？
突き詰めれば排他と同期の問題だろ？

0878デフォルトの名無しさん

2007/07/31(火) 01:41:13

それがお前が考えてるほどそんな簡単なことじゃないからだよ

0879デフォルトの名無しさん

2007/07/31(火) 12:36:24

>>877
なんで人間がこんなに繁殖してるの？
突き詰めればチンコとマンコの問題だろ

0880デフォルトの名無しさん

2007/07/31(火) 15:23:09

それはちょっと突き詰め過ぎだ

0881デフォルトの名無しさん

2007/07/31(火) 15:24:09

突き詰めたいぜ

0882デフォルトの名無しさん

2007/07/31(火) 15:30:13

>>877
マルチスレッドが簡単だと思ったら初心者
難しいと思えるようになってようやく初級脱出

0883デフォルトの名無しさん

2007/07/31(火) 22:05:03

jump、longjump、gotoいっぱい使えば
マルチスレッドなんて楽だ。

0884デフォルトの名無しさん

2007/08/01(水) 00:12:54

50%はスレキチガイなのだ

0885デフォルトの名無しさん

2007/08/04(土) 17:14:46

環状バッファで、書き手と読み手がそれぞれ１つしか存在しないときに

#def MAX 5000
data{
int len
char *data
}

c_buffer{
data d[MAX]
int w_index
int r_index
}

こんな感じでデータ構造作った場合、ロックが必要な場合って
w_indexがMAXから0に戻る場合だけでOK？
それ以外は、wとrが等しければemptyってことでいいと思うんだけど

0886デフォルトの名無しさん

2007/08/04(土) 17:36:16

volatileをつければＯＫ

0887デフォルトの名無しさん

2007/08/04(土) 18:16:00

アトミックな書き込みを保障できるのならいいけど……
なにかそういうAPIかなんか使った方が無難でしょ。

0888デフォルトの名無しさん

2007/08/04(土) 18:24:25

http://www.freewebs.com/photoradio/?1/360788

0889デフォルトの名無しさん

2007/08/04(土) 19:11:04

まぁ、intに限って言えば、アライメントさえ合っていれば現実的には問題ないと思うが。
コメントは付けておいた方がいいかもね。

っていうか、w_indexがMAXから0に戻るときも、ロックいらないんじゃない？

0890デフォルトの名無しさん

2007/08/04(土) 22:08:17

>>885
書き込み時にdataの領域とw_indexの双方の更新が必要だから
メモリバリアがないとOoOの関係で不定になりそうな気がする。

メモリバリアとCASなら何とかなりそうな気もするけど、
循環バッファが埋まっている時の挙動を考えると危なそう。

素直にロックしとくのが一番安全だと思う。

0891デフォルトの名無しさん

2007/08/04(土) 22:32:34

>>890
やっぱりそれだと、毎秒270MBでデータ書き込むので
頻繁にlock呼ぶととんでもなくパフォーマンス悪いです。

うーむなんとかならんものか...

0892デフォルトの名無しさん

2007/08/04(土) 22:59:16

>とんでもなくパフォーマンス悪いです

環境と実測値プリーズ

0893デフォルトの名無しさん

2007/08/04(土) 23:11:24

数10～数100回の書き込み単位でロックしたら？

0894890

2007/08/05(日) 00:06:18

>>891
270MB/秒ってdata内の可変長データでしょ？

1ブロックのデータの平均サイズにもよるんだろうけど、
普通に考えればその内部のデータの処理時間に較べれば
FIFOをロックしてる時間なんて誤差って感じがするけどなぁ。

0895890

2007/08/05(日) 00:13:09

補足しときます。

誤差ってのはロックの競合が少ない場合の話。
FIFO操作くらいの短時間ロックじゃ2スレッドなら
そう滅多に競合しないだろうってこと。

0896デフォルトの名無しさん

2007/08/05(日) 00:22:33

>>894
１ブロック7600byte
データ長[300-7600]可変

これで、270MB/secだから仮りに
全ブロックを毎回ロックした場合
943718回ロックが発生するから
CPUすぐブン回って困るのですよ。

0897デフォルトの名無しさん

2007/08/05(日) 00:28:46

>>896
引っ込めよ、うぜえ

0898デフォルトの名無しさん

2007/08/05(日) 00:43:22

いまだに具体的にどういう処理をしようとしているのか理解できない俺がいる。

0899890

2007/08/05(日) 00:49:55

毎回ロックした場合でも競合さえしなければ普通は速い。
本当にロックがネックになっているのか調べるべき。

lock freeが有意義になるのは複数CPUの場合が多いし、
なんか方向性が間違ってそうな気がする。

0900デフォルトの名無しさん

2007/08/05(日) 00:54:32

300～7600バイトのパケットで270MB/sec
おおよそ 50k packet/sec かな？
これを２スレッド間(reader/writer)で受け渡したい、という話

packetのadd/remove時に一回ずつlockすると
100k locks/sec やることになる

ということでvolatieの導入を考えているらしい

実測しないで語るのがこのスレの掟なのでそこは目をつぶること

0901デフォルトの名無しさん

2007/08/05(日) 00:56:10

ところでReadがWriteに追いついた場合もしくはWriteがReadに追いついた場合は、
それぞれブロックするという動作なの？

0902デフォルトの名無しさん

2007/08/05(日) 00:57:30

busy waitなループで待つに決まってるだろ

0903デフォルトの名無しさん

2007/08/05(日) 00:58:30

単にメモリバリアでいい気がするのは気のせい？

0904デフォルトの名無しさん

2007/08/05(日) 01:01:04

>>903
んじゃ疑似コード出してみ。

0905デフォルトの名無しさん

2007/08/05(日) 01:02:23

いまどきのCPUって、競合のないロックなら数十ナノ秒程度じゃなかったっけ？

0906デフォルトの名無しさん

2007/08/05(日) 01:04:08

バッファサイズを10001にするんだ

0907デフォルトの名無しさん

2007/08/05(日) 01:10:41

>>905
システムコール半端ないほど発生するから
CPUは無駄に食うよ。それがすげー悩みなの

0908デフォルトの名無しさん

2007/08/05(日) 01:14:36

必ずkernel modeに入ると勘違いしている馬鹿発見？

0909デフォルトの名無しさん

2007/08/05(日) 01:58:14

カーネルモードに入る同期機構、およそ1マイクロ秒（とある環境）
カーネルもーぢにはいらないクリティカルセクション等、およそ30倍程度早い（とある環境）

ってイメージがある。

0910デフォルトの名無しさん

2007/08/05(日) 01:59:29

カーネルもーぢｗ

0911デフォルトの名無しさん

2007/08/07(火) 23:45:07

マルチスレッドとクラスを使ったサンプルプログラムを作成しろって言われたのですが、
よくわかんないので面白そうなものが思い浮かびません。
言語はPythonのコマンドラインです。
自分の足りない脳みそでは引数にファイル名を与えて1ファイル1スレッドとかで編集出力とかしようと思うのですが、
何か他に初心者に出来て面白そうな課題ってないでしょうか？

0912デフォルトの名無しさん

2007/08/07(火) 23:51:30

Webサーバ

0913デフォルトの名無しさん

2007/08/07(火) 23:52:54

>>911
指定 URL を http-get & 解析して、img src を並行ダウンロードとかどう?
直列もできるようにして、動作の違いを見れるようにしておくとか。

0914911

2007/08/08(水) 02:29:09

>>913
レスありがとうございます。
なるほど。ダウンロード系の方も面白そうですね。
そういえばregetとかirvineとかあったなぁ。とりあえず脳みそと相談してみます。
他にもありましたら教えてプリーズ

0915デフォルトの名無しさん

2007/08/08(水) 02:35:11

>>914
パケット偽装系のほうが楽しいよ。
実力ついてきたらネトゲの改造とかやると
1ヶ月で300万ぐらい儲かるよ。

0916デフォルトの名無しさん

2007/08/08(水) 02:49:41

信者かるのかよ

0917デフォルトの名無しさん

2007/08/08(水) 14:18:30

信者狩りだー！

0918デフォルトの名無しさん

2007/08/08(水) 14:24:49

もみじ狩りだー！

0919デフォルトの名無しさん

2007/08/08(水) 23:10:09

>911
食事する哲学者の問題とか。

0920デフォルトの名無しさん

2007/08/08(水) 23:31:12

デッドロックするサンプルか！

0921デフォルトの名無しさん

2007/08/08(水) 23:42:34

いやいや、たしか哲学者の食事問題はセマフォを使って回避できるはずだ
だからセマフォのサンプルなんじゃない？

0922911

2007/08/09(木) 01:58:38

>>915
>>919-921
レスありがとうございます。
とりあえず913さんのをベースに作ろうと思います。
食事する哲学者の問題は初めて聞きました。先はながいなぁ・・・

0923デフォルトの名無しさん

2007/08/09(木) 14:29:41

Windowsの_beginthreadexでスレッドを作成しているのですが

子スレッドが孫スレッドを生んだあと親である子スレッドは自らreturnで
死んでしまいました。
孫は自分の親が死んだことも知らず元気に活動しています。
という物語は成立しますか？

0924デフォルトの名無しさん

2007/08/09(木) 14:39:06

>>923
スレッドに親子関係はありません

0925デフォルトの名無しさん

2007/08/09(木) 14:40:26

924がただの荒らしっぽいので追記：
Unix のプロセスの様な親子関係は、Win32のプロセスやスレッドにはありません。

0926デフォルトの名無しさん

2007/08/09(木) 15:06:10

>>924
>>925
ありがとうございました。

0927デフォルトの名無しさん

2007/08/09(木) 20:13:36

なんかさー
線形リスト１要素ごとに
mutex用の変数あるってきもくね？

0928デフォルトの名無しさん

2007/08/09(木) 21:01:18

リスト全体をロックするとスケーラビリティが落ちると思ったのかもしれない。

0929デフォルトの名無しさん

2007/08/09(木) 21:04:07

>>928
そんなことねーだろwそんなケースあるのかよw

0930デフォルトの名無しさん

2007/08/09(木) 21:38:02

ロックの分散を意図してるケースならよくあるぞ？

0931デフォルトの名無しさん

2007/08/09(木) 21:39:22

>>930
１：１でそれはないだろw

0932デフォルトの名無しさん

2007/08/09(木) 23:38:52

>>931
要素の値のポインタの書き換えに使うケースもある。
リストのリンク関係を更新しないなら全体のロックは不要。

0933デフォルトの名無しさん

2007/08/10(金) 01:15:09

それはインタロックすらいらないケースではないのか？

0934デフォルトの名無しさん

2007/08/10(金) 11:45:32

インターロックというか、メモリバリアは要るんじゃない？

0935デフォルトの名無しさん

2007/08/10(金) 11:46:20

>>933
要る要らないは条件次第。
例えば、pthreadにはアトミック操作関数ないし、
コヒーレンシの保証には同期関数が必要だし。

そもそも「キモい」じゃなくて、要不要、効率面とかで語れと。

0936デフォルトの名無しさん

2007/08/10(金) 11:56:57

pthreadってメモリバリアもないんだっけ？

0937デフォルトの名無しさん

2007/08/10(金) 14:57:05

>>931
Win32 の CRITICAL_SECTION とか linux カーネルのスピンロックみたいな
軽い奴なら 1 : 1 で良いかもしれないと思う。管理も楽だし。

0938デフォルトの名無しさん

2007/08/10(金) 18:37:36

lockで競合するくらいならその方がいいってことはあるだろう。

0939デフォルトの名無しさん

2007/08/10(金) 21:11:02

書くだけスレッドと読むだけのスレッドが
1:1の場合って排他制御する必要あるにょ？

書きまくって読みまくればいいよね？

0940デフォルトの名無しさん

2007/08/10(金) 21:53:41

>>939
それも条件次第。
x86では整列境界に沿ったワード操作はアトミックだが、
全てのCPUがそうとは言い切れない。

複数CPUの場合にはメモリバリアが必要なケースもあるし、
更新された値の反映が遅れても構わないなら無くても問題にならない。

0941デフォルトの名無しさん

2007/08/10(金) 22:35:33

最近はマルチコア流行ってるからね。
ちゃんと排他制御するかメモリバリア張っといたほうがいいと思うよ。

0942デフォルトの名無しさん

2007/08/10(金) 22:41:24

メモリバリア命令ってどうやって使うの？
よくわからない....

0943デフォルトの名無しさん

2007/08/10(金) 22:47:09

環境は？コンパイラは？

0944デフォルトの名無しさん

2007/08/10(金) 23:03:03

Linux gcc 3.4 64bit

0945デフォルトの名無しさん

2007/08/10(金) 23:42:15

だからメモリモデルやらが明確でない環境ではやりたくない。
.NETとかJavaとか比較的仕様が明確な環境でしかやる気がしない。

0946デフォルトの名無しさん

2007/08/11(土) 00:08:15

64ビット・・・ごめん、詳しくない。

最近の gcc にはアトミック演算のビルトイン関数があって、メモリバリアを張ってくれたりもするんだけど、そのバージョンで使えるかどうかは知らない。
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html

たぶんアセンブラコードを書かなきゃないかも。

0947デフォルトの名無しさん

2007/08/11(土) 00:10:43

>>945
Java はいいよね、こういうところは。 .NET は知らないや。

0948デフォルトの名無しさん

2007/08/11(土) 00:34:24

memcpyとかもアトミック演算で囲まなくていいよね？
あれは中でやってくれてるよね？

0949デフォルトの名無しさん

2007/08/11(土) 00:37:31

やってくれない。

0950デフォルトの名無しさん

2007/08/11(土) 00:41:50

まじかじゃあ自分でmfanceとか用意してやらなきゃ
いかんというわけか

0951デフォルトの名無しさん

2007/08/11(土) 00:47:09

だから、そういう事を考えたくないならmutex等を使えと。

0952デフォルトの名無しさん

2007/08/11(土) 00:48:36

素直に mutex とか CRITICAL_SECTION とか使っとけばいいよ・・・
あれらはちゃんと入口と出口でメモリバリアかけてくれてるから。

自分でメモリバリアなんか扱うのは、mutex 実装してる人とか OS の中を作ってる人とか、
あとどうしてもパフォーマンスが気になる速度狂な人くらい。

0953デフォルトの名無しさん

2007/08/11(土) 00:53:14

pthreadやWin32 APIにも
Java相当のvolatile read/writeやCASが追加されるんじゃね？
その辺の仕様が固まった時期より有効性が認められているだろうし。

0954デフォルトの名無しさん

2007/08/11(土) 00:54:10

FPGA使ってるから、mutexじゃ間に合わねーの
ほぼDDR2 533と同速度でデータ流れてくるから
こえーのなんのって

0955デフォルトの名無しさん

2007/08/11(土) 00:59:52

そりゃ大変そうだ・・・がんばれ

0956デフォルトの名無しさん

2007/08/11(土) 01:00:34

そんな環境じゃPOSIX仕様での保証とかどうでもいいよね。
好きなだけインラインアセンブラ使ってくれｗ

0957デフォルトの名無しさん

2007/08/11(土) 01:04:33

ここはちょっと妥協して
#define membar() asm volatile("mfence":::"memory")
でいこうと思います。
これでもおせーんだよなぁって場合は工夫しないとなw
きっとまだ足りないはずだ

0958デフォルトの名無しさん

2007/08/11(土) 01:35:23

条件が後から後からでてくる。いい流れだ。

0959デフォルトの名無しさん

2007/08/11(土) 02:05:17

書き込みだけの場合は sfence とか読み込みだけの場合は lfence とか・・・
どの程度違うかわからんけどね。

0960デフォルトの名無しさん

2007/08/12(日) 16:08:31

＞x86では整列境界に沿ったワード操作はアトミックだが、
＞全てのCPUがそうとは言い切れない。

＞複数CPUの場合にはメモリバリアが必要なケースもあるし、
＞更新された値の反映が遅れても構わないなら無くても問題にならない。
なんでやねん

0961デフォルトの名無しさん

2007/08/12(日) 16:29:33

どの点が疑問なのか具体的に指摘してくれないと答えらんない

0962デフォルトの名無しさん

2007/08/12(日) 16:49:28

おいおい、volatileでカンペキだろ？

0963デフォルトの名無しさん

2007/08/12(日) 16:50:37

volatileはコンパイラに対するヒントでしかないので、完璧かどうか知る由もありません。

0964デフォルトの名無しさん

2007/08/12(日) 16:50:52

C/C++ の volatile は全然カンペキじゃない。

0965デフォルトの名無しさん

2007/08/12(日) 17:13:51

volatile で完璧かどうかはともかく、
volatile が単なるヒントだなんてことはない。
そんな信用ない実装だったら
メモリマップド I/O なんて危なっかしくて使えない。

0966デフォルトの名無しさん

2007/08/12(日) 17:46:15

んにゃ、対象が外因によって変更される可能性があるから最適化の対象にするなというヒントでしかない。
アクセスごとに、外部との同期を取るような保証は全くないよ。

0967デフォルトの名無しさん

2007/08/12(日) 17:47:58

>>966
ヒントじゃなくて強制だよ。

0968デフォルトの名無しさん

2007/08/12(日) 18:28:15

同期を取る保証はないけど、最適化をしないという保証はある。

0969デフォルトの名無しさん

2007/08/12(日) 18:57:36

お前らFPGAなんて使ったことねーからわからねーんだろ（笑）
役立たずは黙っててくれー

0970デフォルトの名無しさん

2007/08/12(日) 19:00:03

>>969
専門知識があるやつ以外お断りなら専用スレ立ててそこでやれよ。

0971デフォルトの名無しさん

2007/08/12(日) 19:31:23

>>969
FPGAなんか使ったことないよ。つーか、あんたはFPGAなんか使っているのかね。

0972デフォルトの名無しさん

2007/08/12(日) 19:36:45

お前らシロウトなの？
毎秒270MBでデータが流れ込んでくるんだぞ
FPGAとはそういう世界

0973デフォルトの名無しさん

2007/08/12(日) 19:52:29

>>972 だから何？

0974デフォルトの名無しさん

2007/08/12(日) 19:53:00

もう触るなよ。

0975デフォルトの名無しさん

2007/08/12(日) 19:53:23

ワードの読み書きがアトミックではないかも知れないと言いながら
反映が遅れてもいいなら問題ないって、そんなわけあるかい。

0976デフォルトの名無しさん

2007/08/12(日) 19:56:00

そもそもアトミックに読み書き出来ないならメモリバリアでも足りない

0977デフォルトの名無しさん

2007/08/12(日) 20:16:29

>>975
940はそんなこと言ってないが。

0978デフォルトの名無しさん

2007/08/12(日) 20:28:28

あのなー
こっちはFPGAで270MB毎秒のデータを処理せにゃならんの
チマチマ排他なんかやってらんないの
わかんないかなー

0979デフォルトの名無しさん

2007/08/12(日) 20:33:26

判らん。
なんで、高々270MiB/SecのデータごときでFPGA云々言わなきゃならんのか。
#FPGA使えることをよっぽど自慢したいのかな?

0980デフォルトの名無しさん

2007/08/12(日) 20:47:18

FPGAなんて小さい会社でしか使わないけどな。
でかいところはASIC使うし。

0981デフォルトの名無しさん

2007/08/12(日) 21:12:13

触るなってば。

0982デフォルトの名無しさん

2007/08/12(日) 21:22:33

>>977
なるほど

0983デフォルトの名無しさん

2007/08/12(日) 22:42:19

>>978
それをIntelさん相手に言ってあげてください
きっと驚いてしまうでしょう

0984デフォルトの名無しさん

2007/08/13(月) 00:12:50

>>978
>こっちはFPGAで270MB毎秒のデータを処理せにゃならんの
>チマチマ排他なんかやってらんないの
>わかんないかなー

でも、本当に多量のデータを処理してるのは石の方であって、
>>978 自身ではないと思うんだがなぁ。。。

0985デフォルトの名無しさん

2007/08/13(月) 01:06:54

あのー978は俺じゃないよw
ちなみに普通のワークステーションでも処理できるけど
リアルタイムにデータ解析できるからFPGA使ってますよ

0986デフォルトの名無しさん

2007/08/13(月) 01:56:14

http://free.flop.jp/1chipmsx/

0987デフォルトの名無しさん

2007/08/13(月) 13:20:16

>>975
よく読め。条件次第の例を二つ出しただけだ。

上は特殊なCPUのケース、
下はメモリバリアの必要性も条件次第の意味。

0988デフォルトの名無しさん

2007/08/13(月) 13:31:28

ところで、lock freeな配列リングバッファって実現されてんの？
連結リストな待ち行列しか見たことないんだけど。

0989デフォルトの名無しさん

2007/08/13(月) 13:56:00

それってどういう動きするもんなの？

0990デフォルトの名無しさん

2007/08/13(月) 14:04:40

つまり要領固定のブロッキングキューみたいなのか、
それともブロックしないものなのか…

0991デフォルトの名無しさん

2007/08/13(月) 15:12:44

質問があります，
read/writeシステムコールってスレッドセーフ？
おんなじfdに複数スレッドでよってたかって書き込んでもOK？
順番は考慮しないものとして．

0992988

2007/08/13(月) 15:26:25

Javaで言うBlockingQueueだとlock freeな意味ないから、
enqueue/dequeue出来ない場合はfalse/null返す感じの。

あんまり意味無さそうなんだけど、
>>885のやりたい事ってこれでしょ？

内側にlock freeな配列リングバッファ、
外側に条件変数使ったBlockingQueueを被せる感じ。

どのみちenqueue時にはdequeue待ちしているスレッドに
通知しなきゃいけないからlock freeの意味ないんだけど。

0993デフォルトの名無しさん

2007/08/13(月) 15:27:39

>>991
一般的にはスレッドセーフ。
正確なところは使っているOSのマニュアル嫁。

0994デフォルトの名無しさん

2007/08/13(月) 16:02:57

思いつきで書いてみた。動作確認はしてない。
public class LockFreeRingBuffer<E> {
int capacity;
AtomicReferenceArray array;
AtomicInteger head, tail, elements, spaces;
public LockFreeRingBuffer(int capacity) {
this.capacity = capacity;
array = new AtomicReferenceArray(capacity);
head = new AtomicInteger(0);
tail = new AtomicInteger(0);
elements = new AtomicInteger(0);
spaces = new AtomicInteger(capacity);
}
public boolean enqueue(E element) {
if (element == null) throw new NullPointerException();
for (;;) {
int n = spaces.get();
if (n == 0) return false;
if (spaces.compareAndSet(n, n - 1)) break;
}
int index = head.get();
while (!array.compareAndSet(index % capacity, null, element)) {
index++;
}
head.getAndIncrement();
elements.getAndIncrement();
return true;
}

0995デフォルトの名無しさん

2007/08/13(月) 16:03:55

public E dequeue() {
for (;;) {
int n = elements.get();
if (n == 0) return false;
if (elements.compareAndSet(n, n - 1)) break;
}
int index = tail.get();
E element;
for (;;) {
element = array.getAndSet(index % capacity, null);
if (element != null) break;
index++;
}
tail.getAndIncrement();
spaces.getAndIncrement();
return element;
}
}
もうちょっと減らせないもんかな・・・

0996デフォルトの名無しさん

2007/08/13(月) 16:19:04

そろそろ誰か次スレよろ

0997988

2007/08/13(月) 16:49:43

spacesとelementsをそれぞれenqueue/dequeueの確定と扱ってるのか。
お互いに対になる要素数を最初と最後に更新して干渉を防いでるんだよね。

「空きがある or 要素がある」を先に確定した上で、
headとtailを対象要素の確定に先だったヒントして扱って
配列中の空要素への追加や有効要素の取得を行う、と。

配列要素の入れ替えあたりでモヤモヤが残る気がするんだけど、
これで良さそうな気もする。うまく説明出来ないんだけどさ。

この手のアルゴリズムの検証ってどうやってやってるんだろう？

0998デフォルトの名無しさん

2007/08/13(月) 21:21:36

おーい、それでFPGAからの270MB毎秒のデータさばけるのかー？
そこんとこが大事なんだけど、分かってるかなー？

0999デフォルトの名無しさん

2007/08/13(月) 21:34:07

よゆーよゆー＾＾

1000デフォルトの名無しさん

2007/08/13(月) 21:36:56

次スレ
http://pc11.2ch.net/test/read.cgi/tech/1187008532/l50

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。

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

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