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

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

1:デフォルトの名無しさん
05/11/03 11:23:05
マルチスレッドプログラミングについて語るスレ。
OS・言語・環境は問わないが、それゆえ明記すべし。

その１ｽﾚﾘﾝｸ(tech板)
その２ｽﾚﾘﾝｸ(tech板)
その３ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
05/11/03 11:24:14
関連モノ

pthread地獄
ｽﾚﾘﾝｸ(unix板)

Pthread -- POSIX Thread Mailing List
URLﾘﾝｸ(www.media.osaka-cu.ac.jp)

3:デフォルトの名無しさん
05/11/03 11:25:03
Pthread関係

The Single UNIX Specification, Version 2 Threads Extensions
URLﾘﾝｸ(www.unix.org)

Multithreading in the Solaris Operating Environment
URLﾘﾝｸ(wwws.sun.com)

Building an open-source Solaris-compatible threads library
URLﾘﾝｸ(www.opensource.hp.com)

Pthread Support in Microsoft Windows Services for UNIX Version 3.5
URLﾘﾝｸ(www.microsoft.com)

Programming with POSIX Threads
URLﾘﾝｸ(www.awprofessional.com)

4:デフォルトの名無しさん
05/11/03 11:25:58
ダグ・リー「Javaスレッド・プログラミング
並列オブジェクト指向プログラミングの設計原理」
URLﾘﾝｸ(www.amazon.co.jp)

5:デフォルトの名無しさん
05/11/03 12:05:29
>>1
お疲れさん。

6:デフォルトの名無しさん
05/11/03 15:05:45
メッセージ通信がわからん
関数呼び出しが、同期なのに対比して、
同期・非同期よびだしどっちもできる
ことをメッセージ通信っていって区別してんのかな

7:デフォルトの名無しさん
05/11/03 16:51:02
>>6
メッセージキュー使ってるだけでしょ。

8:デフォルトの名無しさん
05/11/03 17:11:08
>>1
OS・言語・環境は問わないと言っているくせに
unix関連だけか？テンプレート書き直せ

9:デフォルトの名無しさん
05/11/03 19:49:44
>>8
じゃあ、テンプレ追加よろしく。

俺からはJava関連をいくつか挙げる。

Java Memory Modelについて
URLﾘﾝｸ(www.cs.umd.edu)
"Double-Checked Locking is Broken"
URLﾘﾝｸ(www.cs.umd.edu)
The JSR-133 Cookbook for Compiler Writers
URLﾘﾝｸ(gee.cs.oswego.edu)

特に下2つはJava以外のプログラマにもお薦め。
メモリモデル関連では↓も面白い。
URLﾘﾝｸ(lse.sourceforge.net)
Linuxでlock-freeアルゴリズムの一つである
RCU(Read-Copy Update)を実装するときの話。

10:デフォルトの名無しさん
05/11/04 02:46:51
ここのスレのひとは、どんなプログラム作ってるんですか？

11:デフォルトの名無しさん
05/11/04 09:31:12
糞スレ立てたり

12:デフォルトの名無しさん
05/11/05 02:06:21
【狂牛情報】アルツハイマーによる死者が50倍以上に　アメリカ

159 - 衆 - 農林水産委員会 - 13号平成16年04月27日 ○山田委員

エール大学神経病理学科外科部門の研究チームの検討を含め複数の研究で、剖検によりアルツハイマー病
あるいは痴呆症と診断されていた患者の三―一三％が実際はクロイツフェルト・ヤコブ病に罹患していた
ことが判明したとしている。米国では毎年アルツハイマー病と診断される患者が四百万人、痴呆症患者は
数十万人が発生していることから、最も少なく見積もって一万二千人以上のクロイツフェルト・ヤコブ病患者
が検出されず、公式統計に含まれない可能性がある。　注：12万人以上と思われる
　　　　　　　　　　　　　　　　　　　　　　　　　　　
実際、アルツハイマー病と診断された死亡患者数は一九七九年には八百五十七例であったものが、
二〇〇〇年には五十倍以上の五万例近くとなった。

159 - 衆 - 農林水産委員会 - 7号平成16年03月18日 ○松木委員　

記事の中に、アメリカでは、アルツハイマー病あるいは痴呆症と診断される人が年間四百万人いるそう
なんです。複数の研究機関の合同研究によると、このうち三から一三％が実際はヤコブ病であったことが
判明しております。少なく見積もっても十二万人はヤコブ病の公式統計に含まれていない可能性がある。

「アルツハイマーや若年性痴呆の中に変異型ヤコブ病患者が」・・米国牛輸入再開に京大医学部教授衝撃的指摘
ｽﾚﾘﾝｸ(dqnplus板)
【ｖＣＪＤ】牛海綿状脳症（ＢＳＥ）と同じ病気“日本人発症しやすい”…厚労省研究班
ｽﾚﾘﾝｸ(scienceplus板)l50

13:デフォルトの名無しさん
05/11/07 10:54:34
ちょっとばっかし知恵を借りたいのだが。

Linuxでとある画像フィルタリング処理を書いている取り引き先から、
マルチスレッド化して処理を高速化してくれと依頼がきている。
2CPUマシンで動かすから1CPUマシンでは動かなくてもいいらしい。
現状では、1枚の画像に対する処理にある程度時間がかかっていて、
それを複数枚処理してから先に進むロジックなのでその部分で
複数枚分のスレッドを起こせば2CPUに適当に分散できるのではないかと考えているらしい。

そこで相談。
・2CPUマシンでマルチスレッド化はどの程度高速化が期待できるか。
#まさか理論どおり2倍になるなんて期待していないが。
・マルチスレッドだとしたらどんな技術を使うことになるのか。
・マルチスレッドではなくマルチプロセスでやるとしたらどうか。

マルチスレッド云々以前に、数千行のmain()をなんとかしてから高速化を検討しろといいたいのだが……
#あ、そのなんとかするのもこっちに依頼が来るらしいのだが、マルチスレッド化と抱き合わせなのがなんともはや。

14:デフォルトの名無しさん
05/11/07 11:03:51
>>13
> Linuxでとある画像フィルタリング処理を書いている取り引き先から、

この処理がCPUボトルネックなら、

> #まさか理論どおり2倍になるなんて期待していないが。

2倍近くになっても何の不思議もないが。

一般論としては、一枚をマルチスレッドで処理してもいいし、
一枚ごとにスレッド割り当ててもいいし。いずれにせよ簡単だろ?

15:13
05/11/07 11:55:10
>>14
レスTHX。

＞2倍近くになっても何の不思議もないが。
スレッド生成のボトルネックが気になるのだけど。
#プロセス生成よりは小さいのだろうけど。

man on wwwで調べてみた。
一枚の処理を分割するのは面倒なので、一枚ごとにスレッド分けるとして、
for (画面枚数分) {
pthread_create();
}
for (画面枚数分) {
pthread_join();
}
なんて安直なコードでもいいものかな?
#だとしたらmain()を分割した段階で半分以上仕事が終わったようなものなんだがw

16:デフォルトの名無しさん
05/11/07 13:08:22
>>15
まあいいんじゃねえ?
一枚ごと独立に処理出来るんでしょ?

画像がでかけりゃメモリの取り合いで遅くなる可能性もあるけど、
まあとにかくやってみればいいと思う。
# 数千行のmain()に画像処理が埋め込まれているわけね…

17:デフォルトの名無しさん
05/11/07 13:39:08
C#スレで質問していたのですがこちらのスレのほうが適切化と思ったので再度質問させていただきます。

たとえば次のような場合どうします?
株価などのように高頻度に値が更新されてそれに対する処理、その値を基にしたほかの株価データをを必要とする計算や表示などを行う必要がある。
値が更新されるー>対象となるデータノードを検索ー>それに対し値などに応じた必要な処理という流れ。
対象となるデータのノード数は10万単位。ただしすべてメモリ処理するものとする。
複数のノードにまたがる更新処理はない。
ノードの削除処理はない。

こんな場合どんなロックの粒度にしてどんなデータ構造にします?
自分の場合だとデータノードをインスタンスとしてそれをコレクションクラスにぶっこんであるとして、データノードにその変化に応じて処理するobserverが引っ付いている。
コレクションクラスをロックー>データノード検索ー>コレクションクラスのロック解除ー>ノードの必要な箇所にロック->
ノード内の関連データをその部分にロックかけながらアトミックにupdate->
該当箇所のロックをはずしobserverに通知->各observerがおのおの独自の処理を行う。その際におのおの必要なロックをかける。
こんなんなんですが、皆さんはどんな風にされるんでしょう?

18:13
05/11/07 13:52:40
>>16
＞まあいいんじゃねえ?
うい、THX。

＞一枚ごと独立に処理出来るんでしょ?
そそ、全画像処理後、集計してフィルタリングパラメータを変える繰り返し。

＞画像がでかけりゃメモリの取り合いで遅くなる可能性もあるけど、
＞まあとにかくやってみればいいと思う。
小さい小さい。最大128x128。
#なのに現状は2048x2048x16の実数値バッファがグローバルに固定で取られてて(512MB!)泣けます。

＞# 数千行のmain()に画像処理が埋め込まれているわけね…
そそ、あのパラメータを変えてフィルタリング、このパラメータを変えてフィルタリング、
って具合に同じ処理が繰り返し登場するのでその行数。
これをばらしてメモリを必要なだけ動的確保してやれば
1スレッド辺りのメモリ使用量も1MB程度に抑えられそう。

19:デフォルトの名無しさん
05/11/07 15:58:55
>>18
> 小さい小さい。最大128x128。

小さすぎてスレッド生成のオーバーヘッドが気になる時は、
スレッドプール使ってください。

20:13
05/11/07 17:06:30
>>19
オーバーヘッドが大きいようならスレッド分割単位を見直すから多分問題にはならないと思うのだけど、
参考までにスレッドプールとは何か、ポインタを示してもらえませんか?
#ぐぐったけどWebアプリか.NetかC#かJavaの話題しか見つからなかった。

21:デフォルトの名無しさん
05/11/07 17:26:57
>>20
URLﾘﾝｸ(users.actcom.co.il)
URLﾘﾝｸ(www.cs.cf.ac.uk)
URLﾘﾝｸ(www.humanfactor.com)
URLﾘﾝｸ(vergil.chemistry.gatech.edu)

URLﾘﾝｸ(www.kegel.com)

22:13
05/11/07 18:12:55
>>21
THX。
一通り読んでみます。
#日本語で検索してたよ_/￣|○

23:デフォルトの名無しさん
05/11/07 19:30:54
>>13
ちょっと待てよ、お前。
さっきから聞いてりゃ言いたいことぬかしやがって。
飯食ってんだろ？できる見込みないものを依頼受けるなよヴォケ。
お前の相談は「丸投げ」なんだよ。ここは宿題片づけスレか？
気になるなら自分で実験したらいいべ？

24:13
05/11/07 21:25:15
>>23は、せっかくいいこと言っているのに、最後の
「いいべ」という田舎者丸出しの言い方で
説得力が無くなってしまった。

25:デフォルトの名無しさん
05/11/07 21:36:15
華麗に>>17がスルーされてる件について

26:デフォルトの名無しさん
05/11/07 22:05:23
C#わかんねえんだもん

Javaで我慢してくれ。
Overview of package util.concurrent Release 1.3.4.by Doug Lea
URLﾘﾝｸ(gee.cs.oswego.edu)

27:13
05/11/07 22:22:05
取り敢えず>15に書いたような簡単なサンプルは作ってみましたが何か。
余りに単純すぎてスレッドが複数実行しているかどうか判らないような代物ですが。
水曜に客先の端末(2CPU)で分散処理するかどうかは見てくる積もり。

#あー、そもそも依頼を受けたかどうかは書いてない罠。

28:デフォルトの名無しさん
05/11/07 22:24:23
>>27
xosview動かして、1CPU版と比べたら、分かるかも～

29:デフォルトの名無しさん
05/11/07 22:32:49
ランチャー作って二つプロセス起動させれば
全てOK。

30:デフォルトの名無しさん
05/11/08 21:27:03
ｽﾚﾘﾝｸ(tech板:396番)

これホント?

31:デフォルトの名無しさん
05/11/08 22:22:38
YOU行ってみちゃいなよ。

32:デフォルトの名無しさん
05/11/08 23:22:59
むしろ↓がきになる

Java Concurrency in Practice
by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea
URLﾘﾝｸ(www.amazon.com)

なにこのメンバー

33:デフォルトの名無しさん
05/11/12 22:57:52
// TEMPファイルを作成する関数の様なもの。このままスレッドで使うとバグる。
char * create_unique_file(char *file) {
　FILE *fp;
　if(NULL != (fp = fopen(file, "rb"))) {
　　// 同名のファイルが既に存在する。
　　fclose(fp);
　　// ※ここで違うファイル名を生成する処理を行う。
　} else {
　　// 同名のファイルが存在しないのでそのままのファイル名でファイルを作成する。
　　if(NULL != (fp = fopen(file, "wb"))) {
　　　// ここにきてほしい。
　　　fclose(fp); return file;
　　} else {
　　　// なぜかここにくる場合がある。errno:13(EACCES)
　　}
　}
　return NULL;
}
// 上の関数をマルチスレッドで使うために若干のセーフティーを加えてみた。
void funk(char *file) {
　EnterCriticalSection(&cs);
　create_unique_file(file);
　Sleep(100);// これをコメントアウトするとバグる(時間が短いとバグりやすい？)。
　LeaveCriticalSection(&cs);
}
// 上側の関数をマルチスレッドプログラム(HTTPDもどき)で使用していたところなぜかバグります。
// ・"wb"が失敗する。及び、プログラム全体のファイル送信がおかしくなる。
// 下側の関数のようにしたところ、
// ・Sleep(50～)を入れると両方のバグが(見た目)出なくなる。
// fopen()が極短時間で重なっておかしくなっているのではないかと思っています。
// どうなんでしょうか・・・

34:デフォルトの名無しさん
05/11/12 23:24:42
>>33
排他していない版は、典型的なバグだね。

static int a;
static void foo()
{
　while(a != 0){
　}
　// <-- (A)
　a = 1;
　// 処理
　a = 0;
}

と同じ。
(A) の所で、スレッドが切り替わって同じルーチンが呼ば
れた時を考えればなぜバグっているかわかるはず。

ところで、排他制御を追加した版でも Sleep() がないと、
> // ・"wb"が失敗する。及び、プログラム全体のファイル
> 送信がおかしくなる。
の現象が出るの？

ちなみに、シングルスレッド用のライブラリをリンクしてるっ
てことはないよね。

35:デフォルトの名無しさん
05/11/12 23:26:03
>>33
> 　　if(NULL != (fp = fopen(file, "wb"))) {

freopen()しろ、この呆けが！

36:デフォルトの名無しさん
05/11/12 23:31:39
URLﾘﾝｸ(www-06.ibm.com)

37:33
05/11/12 23:38:59
>>34 >>35 >>36どうもです。

更に実行しまくってたらクリティカルセクション＋Sleep()でもバグが出てます；；

>ちなみに、シングルスレッド用のライブラリをリンクしてるっ
>てことはないよね。
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winsock2.h>
#include <stdio.h>
って感じでインクルードしてます(これらを用いて作成した関数群など)。外部のライブラリなどは使用していません。
"シングルスレッド用のライブラリ"を意識したことがないのですが、
"シングルスレッド用のライブラリ"ってことは<stdio.h>や<windows.ｈ>のマルチスレッド用のがあるとかですか？
#define MULTI_THREAD// こんな感じの。
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winsock2.h>
#include <stdio.h>

38:デフォルトの名無しさん
05/11/12 23:41:26
>>37
シングルスレッド・マルチスレッド用のライブラリの切り替えは、
VCならプロジェクトのプロパティの中のどこかにあるはず。
ただしここでいうライブラリはCランタイムライブラリのことなのでWinAPIは関係ない。

39:デフォルトの名無しさん
05/11/12 23:49:25
ファイル名を返すかわりに直接ハンドルでも返せば？

40:33
05/11/13 00:04:52
>>36
読んでいます難しいです；

>>38
CLコマンドでコンパイルしているのですが/MTオプションを指定してみました。
ファイル送信のバグは今のところ目に付かなくなりました。
しかし"wb"のほうが激しくなりました。
ちなみにCとAPIのみで作成しています。
マルチスレッド用のライブラリについて調べてみようかと・・・

>>39
"rb"のかわりにGetFileAttributes()で判定するようにしてもだめでした。"wb"が開けないのはどうにも・・・

41:デフォルトの名無しさん
05/11/13 00:18:47
まさか、InitializeCriticalSectionしてないとか？
あるいは、違うファイル名を生成する処理がおかしいとか。
あるいは、戻ってきたファイル名の扱いがヒドいとか。

42:デフォルトの名無しさん
05/11/13 00:25:13
>>40
> ちなみにCとAPIのみで作成しています。

へぇー fopen() と言う API がある OS もあるんだ…。

あと、>>39 は、GetFileAttributes() なんかにつ
いて言ってるんじゃないと思う。

そもそも、ファイル名返してもそのファイルを書き込み
オープンする前に他のスレッドが書き込みオープンする
かもしれない。つまり、funk() から戻った時に既に
そのファイル名のファイルが作られてるかもしれないか
ら、ファイル名なんか返しても意味がない。

43:デフォルトの名無しさん
05/11/13 00:33:11
そうそう、普通に「そのまま使える物」を返すか
単に「呼ぶ度に違う名前を生成する関数」を作って、ファイルが開けなければ再試行するとか。

後者のものは、C標準にあるけどな。

44:33
05/11/13 00:45:38
>>41
それは・・・ないとおもいますっ；＞＜

>>42
vc++をインストールしているがコマンドラインでコンパイルしてて
MFCは使わずc言語標準関数とWin32APIで作ってます。

fopen()やfclose()を繰り返すのがまずいのかなと思い"rb"のfopen()を使わないようにしたのを作ってみましたが結果は同じでした。
"wb"がfopen()できないのにファイルポインタは返せないのでは？
初めのを閉じずに使用すれば次のもバグらなくなってウマーということでしょうか。

45:33
05/11/13 01:02:38
とりあえず閉じずに返すようにしてみます。

46:デフォルトの名無しさん
05/11/13 01:29:19
>>44
すまん、>>42 で大嘘書いてた。
fopen(～, "wb") でファイルが作られるから、他のス
レッドがそのファイルを作ることはないはず。まあ、でも
わざわざファイル名を返して戻った先で再度オープンする
ならそのままファイルハンドルを返せばいいと思う。

そもそも、俺なら fopen(～, "a") でファイルを開い
て、fgetpos() で取得したファイルポインタが 0 なら、
そのままそれを返すし、0 でなかったら違うファイル名で
再トライを繰り返すように作ると思う。

47:デフォルトの名無しさん
05/11/13 01:41:44
（他と衝突しない）ファイル名を作る
ファイルを書き込み＋排他で作ってファイルポインタを返す
の一連の処理をクリティカルセクションでやるのはどうか．

>>42の「そもそも～」は合ってると思う．
>>33の関数だとファイルを "wb" で作っても fclose ですぐ閉じる
ようになってるから．すでにあるファイルを "wb" で開くと
元のファイルは破壊される．

48:33
05/11/13 03:30:42
TEMPファイルの作成は通し番号で作成するようにしたところバグがでなくなりました。
何とかいけそうです。

現在スレッドを作成するのにCreateThread()関数を使用しています。
調べているとCランタイム関数を使う場合CreateThread()はまずいようです。
以前から、rand()やsrand()を使っているプログラムでもCreateThread()を使っており謎のバグが発生しておりました。
とりあえず_beginthread()を使うように書き直してみます。
今は/MTオプションをつけなくてもコンパイルは通っています。

これが致命的だったのかもorz

49:デフォルトの名無しさん
05/11/13 08:20:26
なぜFILE*を返さないのかわからん。
OSが提供するロックのようなものなのに。

> これが致命的だったのかもorz

_beginthreadexにするのは正しいが
33でやろうとしている内容であれば問題は起きない

50:>>46
05/11/13 10:12:04
>>47
> >>33の関数だとファイルを "wb" で作っても
> fclose ですぐ閉じるようになってるから．すでに
> あるファイルを "wb" で開くと元のファイルは破
> 壊される．

いや、排他が入ってる版ならその前の
fopen(～, "rb") のファイル存在チェックではね
られるから「すでにあるファイルを "wb" で開く」
ことはないはず。

>>48
> TEMPファイルの作成は通し番号で作成するように
> したところバグがでなくなりました。

おいおい、前はどうやってたんだよ…。

> 今は/MTオプションをつけなくてもコンパイルは通っ
> ています。

コンパイルが通れば OK なんて考えてるうちは、マルチ
スレッドプログラムなんか組まない方がいいと思う。

51:33
05/11/14 08:02:54
TEMPファイルの作成は、
以前はtmp.txtが既に存在する場合はtmp(1).txtが存在する場合はtmp(2).txtみたいにしてました。
通し番号の方はtmp1.txt次はtmp2.txt次はtmp3.txtを問答無用に作成するようにしました。

_beginthread()を使用するようにしたところ、以前は謎のアクセスバイオレーションが発生していたのですが
それ以前にどうみてもヌ○ポを踏んでいるようなエラーが出ます。
なんとなくSleep()でタイミングをずらしてみたところエラーが出なくなったりします。

マルチスレッドの場合、同じメモリ領域を同時に”読む”のもNGですか？
if(NULL != *hoge)と*p = hoge;やi = hoge->num;が別スレッドで同時に起きるような場合もNGですか？

52:33
05/11/14 08:08:11
踏んでいる場所を見つけようとチェックを埋め込んでみてもつかまりません。
自分で書いたコードよりも奥の方で発生しているようです・・・。

53:デフォルトの名無しさん
05/11/14 08:11:48
もはやマルチスレッド関係ないだろ。
初心者スレに行け。
create_unique_file()の稚拙なロジックが痛々しい。

54:33
05/11/14 08:14:51
×if(NULL != *hoge)
○if(NULL != hoge) // hogeは構造体へのポインタです。

痛々しいロジックの方は忘れてください；＞＜

55:デフォルトの名無しさん
05/11/14 11:16:38
＞以前はtmp.txtが既に存在する場合はtmp(1).txtが存在する場合はtmp(2).txtみたいにしてました。
こんな文章しか書けないくらいだから、コードもとっ散らかってるんだろ。
小学校辺りから「頭の使い方」を勉強しなおしてみたら?

56:デフォルトの名無しさん
05/11/14 17:20:12
重複しないテンポラリファイルなんて、API使えば一発だろ。

57:デフォルトの名無しさん
05/11/14 23:23:11
>マルチスレッドの場合、同じメモリ領域を同時に”読む”のもNGですか？

スレッド生成前にメモリ領域を確保して値しかいじらないのなら、同時に読んでもOK
マルチプロセッサではメモリバリアを使って同期すればOK
メモリ領域を複数スレッド内で確保と消去をくり返すような場合はリードライトロック。

> if(NULL != *hoge)と*p = hoge;やi = hoge->num;が別スレッドで同時に起きるような場合もNGですか？

別スレッドが *hoge ポインタの示す場所をいじるのなら、同期しないと全部アウト。

58:デフォルトの名無しさん
05/11/15 01:05:11
>マルチスレッドの場合、同じメモリ領域を同時に”読む”のもNGですか？

intサイズだったらOKだよ。
前スレでそういう結論になった。

59:33
05/11/15 05:26:59
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　作成された子スレッド内部で継続中flagを立てる前に
|　親スレッドでflagチェック→終了判定→構造体NULLクリア
|　していたのがNULLを踏む原因でした。
＼
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　おめーのバグだな、
　（　　⊃ ）　 (　ﾟДﾟ)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿
￣￣￣日∇￣＼| NullPo |＼　　ﾅﾝﾄｶﾅﾘｿｳﾃﾞｽ
　　　　　　￣　　　=======　　＼　ｲﾛｲﾛﾄﾄﾞｳﾓｱﾘｶﾞﾄｳｺﾞｻﾞｲﾏｼﾀ

60:デフォルトの名無しさん
05/11/15 08:03:23
親でflag立ててから呼べばいいじゃん。

61:デフォルトの名無しさん
05/11/20 03:06:17
ｽﾚﾘﾝｸ(tech板:312-317番)
に書いたんだが、誘導されました。
返答求む。

62:デフォルトの名無しさん
05/11/20 16:27:20
windows には win32 API で色々なイベントを使えるようになってますが、
UNIXではpthreadのイベントを使う以外にないのでしょうか？

63:デフォルトの名無しさん
05/11/20 16:46:47
はぁ?

64:デフォルトの名無しさん
05/11/20 17:19:57
>>62
意味がわかんない。
自分が言ってる単語について全部調べてみたら？
わかんない言葉は使うもんじゃないよ。

65:デフォルトの名無しさん
05/11/20 17:29:22
セマフォをつかって、ある処理に関してロック、アンロックの処理が
したい場合、ソースは以下のようなかんじ問題ないですか？
※以下のプログラムを２つ同時に動かした場合、
セマフォの開放は1つ目のプロセスによって行われているので、
2つ目のプロセスはIPC_RMIDの際に、エラーが出てしまいますよね。
これって、基本的にはどうするといいんですかね？

66:65
05/11/20 17:29:42
#include <stdio.h>　#include <stdlib.h>　#include <unistd.h>　#include <sys/types.h>　
#include <sys/sem.h>
union semun { int val;
struct semid_ds *buf; unsigned short int *array;
struct seminfo *__buf; };
int lock(int argc, char *argv[]) {
union semun semaphore_union;
struct sembuf semaphore_buffer;
int semaphore_id;
semaphore_id = semget((key_t)1000, 1, 0666 | IPC_CREAT);
semaphore_union.val=1; //sem init
if ( semctl(semaphore_id, 0, SETVAL, semaphore_union) != 0 ) {
exit(1); } //lock
semaphore_buffer.sem_num = 0;
semaphore_buffer.sem_op = -1;
semaphore_buffer.sem_flg = SEM_UNDO;
if ( semop(semaphore_id, &semaphore_buffer, 1) == -1 ) {
exit(1);　 }
sleep(30) // 何かの処理の変わり　 //unlock
semaphore_buffer.sem_num = 0;
semaphore_buffer.sem_op = -1;
semaphore_buffer.sem_flg = SEM_UNDO;
if ( semop(semaphore_id, &semaphore_buffer, 1) == -1 ) {
exit(1);
}
//sem end
if ( semctl(semaphore_id, 0, IPC_RMID, semaphore_union) != 0 ) {
exit(1);
}
return(0);
}

67:65
05/11/20 17:30:42
//sem end
if ( semctl(semaphore_id, 0, IPC_RMID, semaphore_union) != 0 ) {
exit(1);
}
　この際に、一つめのプロセスが既に削除しているので、
　2つ目のプロセスでは、エラーが帰ってきてしまいます。
　基本的にセマフォの扱いって、どう記述するものなんですか。

68:65
05/11/20 17:31:19
正しいやり方かはわからないが。
①プロセス１の処理が終わったら、セマフォに「プロセス１終わったよ」書き込む。
②「プロセス１終わったよ」になるまで待機してから、
　「プロセス２も終わったよ」を書き込んでから、プロセス２を削除。
③「プロセス２も終わったよ」を確認してから、プロセス１を削除

69:65
05/11/20 17:31:49
>>68
それぞれのプロセスをIPC_RMIDさせる直前までwait させろってことですよね。
　そのケースは、事前に立ち上がるプロセス数（たとえば、自分で
　　fork して作成したプロセス）が分かっている場合、有効ですよね。
　
　何個のプロセスがあがるか分からないときの手段としては、
　IPC_RMID させる時は、手動で打つがいいのかな。

70:デフォルトの名無しさん
05/11/20 17:35:42
>>65
ここはマルチ「スレッド」のスレだ。
決してマルチ「プロセス」のスレではない。

71:デフォルトの名無しさん
05/11/20 17:38:09
マルチプロセスプロ倉羅民具スレなんてねーんだから
ここでいいじゃん

72:デフォルトの名無しさん
05/11/20 17:39:15
いや、素直にUnixプログラミングスレかUnix板に行くべきだろう。

73:デフォルトの名無しさん
05/11/20 23:03:49
shared libを作ろうとしてまして、
その中でスレッドを起動して使いたいのでつが、
問題ないでしょうか？

74:デフォルトの名無しさん
05/11/20 23:31:14
>69
親が代表してセマフォを造って、削除する。
子供は親の造ったセマフォをみて触るだけ（無ければエラーにする）とか。

セマフォを開いてみて、無ければ造る。
造る時に排他制御して、唯一造れた人が責任をもって廃棄する、とか。

75:65
05/11/21 00:29:05
>>70 >>72
　Unixプログラミングすれから、誘導されたんですよ。
>>74
　実務レベルだと、
　親＝オペレータが、起動スクリプト（セマフォ作成）をたたく。
　　　　サーバー終了時に、終了スクリプトをたたく。

　　　　オペレータ介さないと考えると、init.dに、SXXXXスクリプト）を作成し、
　　　　runレベルに合わせて、起動、終了のシンボリックリンクをはる。
　　　
　なんて感じですかね。
　　　　　　　　　　　　

76:デフォルトの名無しさん
05/11/21 02:49:56
>>75
そりゃ気の毒に、誘導が間違ってる。無責任にこの辺に誘導しとくよ。
「VIPPERでもわかるプログラミング」

77:デフォルトの名無しさん
05/11/21 12:01:13
>>73
過去の経験から言わせてもらうとライブラリ側で勝手にスレッドを起動するような
作りはあらゆる意味で良くない。
どうしても必要ならばまずそのスレッドで起こりえる可能性をすべて列挙してみる。
スレッドが起動するという事、その際例外が発生した場合どういう処置がなされるべきか、など。
判断がつかなければコールバック等でそのスレッドのトップレベルループや
ドメインに該当する処理に対してユーザーが干渉できるようにしたほうがいい。
↑domain
｜user_thunk_procedure
｜thread_callback
これらをドキュメント等も含めきちんと導出できないと第三者にはまず提供できない
代物になる。もしくは欠陥を持ったライブラリが完成する。

78:デフォルトの名無しさん
05/11/22 00:23:28
マルチスレッドの例外処理ってどうやってまつか、みなさん。

79:デフォルトの名無しさん
05/11/22 00:30:02
大域くくって落ちたらやりなおし、
ループでもなんでも、気をとりなおして次の処理。

80:73
05/11/22 01:45:30
>>77
ありがとうございますた、

厳しいみたいでつね、もっと勉強しまつ。

81:デフォルトの名無しさん
05/11/28 01:09:25
winapiスレと迷いましたが、_beginthreadex()に関して質問があります。

現在_beginthreadex(NULL, 0, .....);
としてメモリ割り当てを特に指定していません。

現在は実験のためにあるスレッドをいくつも作りたいのですが、
そうすると、エラーが起こりその原因の場所を調べると
#endif /* _WIN64 */
return HeapAlloc(_crtheap, 0, size);
という箇所でした。毎回ここでエラーが出ているようです。

この原因としてスタック領域のメモリ不足だと自分では思っているのですが、
実際のところはどうなのでしょうか？
また何かいい解決方法を教えていただけないでしょうか？
現在は数十スレですが、将来的には数百スレを扱いたいと考えています。

82:デフォルトの名無しさん
05/11/28 01:33:22
いいえ、その情報だけですとスタックではなくヒープの確保が失敗したと思われます。
マルチスレッド云々以前に初心者歓迎スレ辺りでソースを晒してみては如何でしょう。

83:デフォルトの名無しさん
05/11/28 01:40:39
スレッドが多すぎてヒープ(のアドレス空間)が足りなくなるという可能性も無くはないけど
数十スレッド程度でそんなことになる筈もなく
そもそもスタック領域がヒープを圧迫するかどうかという問題も

84:81
05/11/28 10:47:04
舌足らずですいません。
エラーが起こるのは_beginthreadex()内の処理のようです。
_beginthreadex()を呼び出して目的のスレッドを作成しようとすると
その過程の最中で81のようなエラーが出現してしまいます。

あと、
「メモリがreadになることはありませんでした。」
というメッセージボックスが表示されるのですが
何か関係あるのでしょうか？
スレッド数は32、64、96と増やしていきたいのですが
32の段階でのエラーです。

85:デフォルトの名無しさん
05/11/28 11:28:40
だから、マルチスレッド以前のレベルでバグってるんだろってば。
自分のソースも追えないような蛸なら初心者スレでソース晒せって。

86:デフォルトの名無しさん
05/11/28 13:27:17
> あと、
> 「メモリがreadになることはありませんでした。」
> というメッセージボックスが表示されるのですが

自分で確保したメモリ領域外のアドレスを読みに行ったときに出る．

87:デフォルトの名無しさん
05/11/28 16:58:56
エスパーの俺様が、スレ違いのバグを解決してやろう。

malloc系を呼び出したときにライブラリ内でエラーが起こるのは
ヒープの管理ブロックが壊れている時だ。

つまり、mallocした領域以外をfreeしたり、同じ領域を２度freeしたり
あるいは確保した領域をはみ出して書き込みをした場合に起こる。

88:81
05/11/28 22:43:36
すいませんでした
>87さんのレスを手がかりにmalloc(), free()を中心に調べていったところ
p = (int *)malloc(sizeof(short) * num);
という箇所がありました。
sizeof(int)に直したところ変なエラーはでなくなりました。
心配されていた方々申し訳ございませんでした。

89:デフォルトの名無しさん
05/11/29 00:00:44
だから>82や>85がマルチスレッド以前のバグだって指摘してたのに……

90:デフォルトの名無しさん
05/11/29 04:05:55
うるせえ黙れ

91:デフォルトの名無しさん
05/11/29 08:26:55
>>88
心配してねーよ。
こいつ馬鹿だなと思っていただけ。

92:デフォルトの名無しさん
05/11/29 09:50:47
>>88
誰も心配はしてないとおもいます。アドバイスしてただけ。
日常でもそのような勘違いをしているとなぜあの人は自分のことしか考えないのかと思われるので注意しましょう

93:愛也
05/11/29 15:57:01
質問なんですが・・・・どなたか教えていただけないでしょうか？

(1)
特定のデータを指定するにはアドレス信号を用いる。どれだけのアドレス信号が発行できるかはアドレスバスの本数による。
アドレスバスの本数が８本のときは(　　１　　)個、１２本の時は(　　２　　)個のアドレスを発行する事ができる。

(2)
容量３２ＫＢのメモリがある、このメモリにバイト単位でアドレスをつけた場合（アドレス幅は８ビット）、全アドレスを指定するには、最低(　　３　　)本のアドレスバスが必要である。
同時に２５６ＭＢの場合は(　　　４　　　)本必要である。

上の問題をどなたかお時間がある方がいらっしゃれば教えていただけないでしょうかぁ？？

何卒よろしくお願い致します。

94:デフォルトの名無しさん
05/11/29 16:05:54
>>93
板違い

95:デフォルトの名無しさん
05/11/29 16:43:14
>>93
そのうえ問題自体に間違いがある（ｗ
コピペミスかもしれんが（ｗ

96:デフォルトの名無しさん
05/11/29 20:19:25
HTマシンでpause命令使って効果実感した人いる？

97:デフォルトの名無しさん
05/11/29 23:05:15
メール欄が空ですよ

98:デフォルトの名無しさん
05/12/06 03:43:50
93は、
スレ題名に「マルチスレッドプログラミング相談室」と書いてあるから、
「ここはマ板共用の相談スレに違いない！」と思ったんじゃないの？

99:デフォルトの名無しさん
05/12/06 12:03:49
マ板?

100:デフォルトの名無しさん
05/12/07 16:08:17
Windows でマルチスレッドを実現するには CreateThread API 以外に方法はありますでしょうか？

101:デフォルトの名無しさん
05/12/07 16:55:31
_beginthread

102:デフォルトの名無しさん
05/12/07 21:07:21
>>101
_beginthreadex使えよ。

103:デフォルトの名無しさん
05/12/09 18:32:43
つうか何がしたいんだ

104:デフォルトの名無しさん
05/12/09 18:52:57
いろんな恋がしたい

105:デフォルトの名無しさん
05/12/10 01:12:51
マルチフ恋奴

106:デフォルトの名無しさん
05/12/13 10:40:34
ほしょ

107:デフォルトの名無しさん
05/12/13 22:06:28
>>104
マルチスレッドな恋なんかしてると火吹くぞ

108:デフォルトの名無しさん
05/12/13 23:24:21
俺のセマフォは3カウントまで。

109:デフォルトの名無しさん
05/12/14 00:13:25
セマフォなんてニッチで泥臭いものは今日日使わないよ

110:デフォルトの名無しさん
05/12/14 00:29:54
オレのMutexは一度もLockされたことがない…orz

111:デフォルトの名無しさん
05/12/14 00:32:21
そこはまさにCriticalSectionなので、触れてはいけない。

112:デフォルトの名無しさん
05/12/14 00:33:55
一生一WorkerThread。

113:デフォルトの名無しさん
05/12/14 00:35:11
オレのFutureはいつまでたっても実体を返さない…orz

114:デフォルトの名無しさん
05/12/14 00:36:37
オレのQueueはいつも空っぽ…orz

115:デフォルトの名無しさん
05/12/14 00:44:57
Terminateされたい性分なんです、スレッド失格でしょうか?

116:デフォルトの名無しさん
05/12/14 00:50:19
だれかJoinしてクレー！

117:デフォルトの名無しさん
05/12/14 01:10:22
オレのQueue、気付いたときにはStackになってた

118:デフォルトの名無しさん
05/12/14 01:41:29
恋はいつも非同期(asyncronous)

119:デフォルトの名無しさん
05/12/14 02:02:00
クリスマスなのにDaemonです…orz

120:デフォルトの名無しさん
05/12/14 02:45:54
僕の人生Suspendしています。誰が解除してくれるんですか?

121:デフォルトの名無しさん
05/12/14 03:08:52
俺はreturnしちゃったよ

122:デフォルトの名無しさん
05/12/14 07:50:37
signal投げてくれる筈のプロセスがゾンビになっていた件について

123:デフォルトの名無しさん
05/12/14 07:55:39
それマルチスレッドじゃねーし

124:デフォルトの名無しさん
05/12/14 21:50:08
彼女といつも同期に失敗しまつ

125:デフォルトの名無しさん
05/12/14 21:52:06
俺はいつもシングルスレッド。

126:デフォルトの名無しさん
05/12/15 00:29:14
漏れのセフレはヂュアルコアだから２穴使って楽しめるよ。

127:デフォルトの名無しさん
05/12/17 01:08:57
おまいら、そろそろ戻ってこい

128:デフォルトの名無しさん
05/12/17 04:50:34
goto 107

129:デフォルトの名無しさん
05/12/17 08:34:28
mutex と spin lock の使い分けの基準て何?

130:デフォルトの名無しさん
05/12/17 10:49:07
使い分けってお前

131:デフォルトの名無しさん
05/12/17 15:45:08
mutex: 居間のテレビのチャンネル権取得に使う
spin lock: 朝、トイレの空きを待つ時に使う

132:デフォルトの名無しさん
05/12/17 15:57:25
後者、spin lockになるのはガマン出来ないときに限られると思われ

133:デフォルトの名無しさん
05/12/17 16:18:01
スピンロックって、カーネルモードへの移行よりも短い時間しかブロックされない処理、
例えば単純な変数の読み書きなんかに積極的に使いたくなるのだけれど

シングルプロセッサのシステムで、
ロックしているときにコンテキストスイッチが起きて
別スレッドがロック取得しようとすると
すげー時間が無駄になるんだよね。
それがちょっと嫌。

134:デフォルトの名無しさん
05/12/17 20:56:42
>>133
知ったかはよくないぞ。入社2年目のおぬし。天狗の鼻をへし折られろ。

135:デフォルトの名無しさん
05/12/17 21:16:38
我が社では、spin lock の事を
フレンドリーに「ぐるぐるくん」と呼んでいる。

136:デフォルトの名無しさん
05/12/17 21:35:35
我が社では回転元彌チョップと呼んでいる。

137:129
05/12/17 22:48:09
>>131
よくわからんです

>>133
その単純な変数の読み書き以外に、どうしても spin lock を使い
たいんじゃ! とか、spin lock じゃないとうまくいかないような、
典型的なケースってないすか?

138:デフォルトの名無しさん
05/12/18 00:05:24
>>134
じゃあ、どこがおかしいのか指摘しろよ。
業界最底辺を何年も続けてる事だけが自慢の
低脳プログラマさんよ。

マルチプロセッサでも、
ロックを取得している状態で実行権を奪われたら起こりうるのは確かだけどな。

139:デフォルトの名無しさん
05/12/18 00:40:53
>>138
だれか解読頼む。

140:デフォルトの名無しさん
05/12/18 01:43:49
>>138
お前の存在そのものがおかしいことを指摘してやらんでもない。

141:デフォルトの名無しさん
05/12/18 01:46:16
指摘してほしいのに　しろよ　はないだろ。
せめて、「わたくしは無知なので、できれば、ご指摘いただけないでしょうか？」だろ。
誠心誠意で言葉に気をつけろ。

142:デフォルトの名無しさん
05/12/18 01:51:21
ナニこいつ

143:デフォルトの名無しさん
05/12/18 01:59:03
具体的に指摘しないのは荒らしと同じだから放置汁

144:デフォルトの名無しさん
05/12/18 14:48:34
チョンはすぐにファビョるからやあねえ。

145:デフォルトの名無しさん
05/12/18 18:57:20
Win32（XP）で下のような排他制御を考えないプログラムを書いて
実際にハングするところを確かめたかったのですが、何度実行しても上手くハングしてくれません
たまたま運が良くてハングしなかっただけなのでしょうか？ご教示願います

#include <stdio.h>
#include <windows.h>
#include <process.h>
unsigned __stdcall mythread(LPVOID);
int main(){
unsigned int thID;
HANDLE hTh = (HANDLE)_beginthreadex(NULL, 0, mythread, NULL, 0, &thID);
for (int i = 1; i <= 100; i++) {
FILE *fp = fopen("test.txt", "a");
fprintf(fp, "Main---%d\n", i);
fclose(fp);
}
WaitForSingleObject(hTh, INFINITE);
CloseHandle(hTh);
return 0;
}
unsigned __stdcall mythread(LPVOID lpx)
{
for (int i = 1; i <= 100; i++) {
FILE *fp = fopen("test.txt", "a");
fprintf(fp, "Thread---%d\n", i);
fclose(fp);
}
return 0;
}

146:デフォルトの名無しさん
05/12/18 19:34:13
この程度でハングはしないと思うが、
同期とらない＝ファイルの中身はグチャグチャになるの？　
って意味ならば出力されたファイルを読め。

147:デフォルトの名無しさん
05/12/18 19:38:13
>>146
ファイルもぐちゃぐちゃになりません。きちんと出力されます
また、一度に書き込む文字列のサイズを100KB程度と大きくしてもきちんとと出力されます
しかし、どちらかのスレッドにSleep(0)等を入れる程度でぐちゃぐちゃになります

境界はどこに有るのでしょうか？

148:デフォルトの名無しさん
05/12/18 21:36:48
ヒント：ストリーム系はバッファリングされるから混ざりにくい。

149:デフォルトの名無しさん
05/12/19 00:03:34
fprintf-fcloseの間にスレッドが切り替わらなければセーフ。
んで、100回くらいのループではWindowsのタイムスライスに
引っかからなかったりするのでは。
マルチプロセッサなら、カナリヒドい事になりそうな気がするのだけれど。

150:デフォルトの名無しさん
05/12/19 06:15:26
>>149
> fprintf-fcloseの間にスレッドが切り替わらなければセーフ。

そうとは限らない。

151:デフォルトの名無しさん
05/12/19 10:16:27
>>148
「一度に書き込む」っていってんだから、
バファリングの有無は関係ないような気がするんだけど。

152:デフォルトの名無しさん
05/12/19 21:48:15
そもそもハングするのか？　ハングはしないだろ

153:145
05/12/20 01:28:57
いろいろ調べてましたが
IO絡みの関数は基本的にスレッドセーフに作られてるから
ってのが答えみたいです
お騒がせしました

>>149
それは違います。たとえfcloseをコメントアウトしてもハングしません

>>152
ハングはしないようですね
このページに「大抵ハングしてしまいます」と書かれていて気になったのです
URLﾘﾝｸ(www.kumei.ne.jp)
まあこのページに限らずネット上でマルチスレッドを初心者向けに教えているサイトでは
大抵同じような書かれ方がされてるので、
もしかすると私の検証が不十分なのかもしれませんが･･･

154:デフォルトの名無しさん
05/12/20 04:36:05
同時に書き込んで壊れなくても
後からの書き込みで前の書き込みは上書きされて消える訳だが

155:デフォルトの名無しさん
05/12/24 14:28:30
>>153
ランタイムライブラリがスレッドセーフで無い場合はハングするかもしれないけど、
VS2005からシングルスレッドのランタイムは無くなっているなあ。

156:デフォルトの名無しさん
05/12/24 14:44:54
「ハングする」なんて言い方は止めて、
「動作が未定義」くらいにしてくれないか。
本当にハングアップするかどうかを問題にしているんじゃないだろ?

157:デフォルトの名無しさん
05/12/25 13:24:46
>>156
このマニアめが。

158:デフォルトの名無しさん
05/12/25 13:38:00
/MT ってやってればたいがい大丈夫だろうけど、スレッドセーフでない関数で
gethostbynameとかが未定の動作されるとかなり困る、
無理矢理排他同期とって使ってるけどなんかかっこ悪い。

159:デフォルトの名無しさん
05/12/25 13:45:27
winsockのgethostbynameはスレッドセーフじゃなかったっけ？

160:デフォルトの名無しさん
05/12/25 13:49:25
/MTってことはWindows?
getaddrinfoはMT-Safeでしょ。

URLﾘﾝｸ(msdn.microsoft.com)
には明記してないけど、gai_strerrorは違うから～って書いているくらいだから。

161:デフォルトの名無しさん
05/12/25 13:54:49
明記してあるな。

>Remarks
>The gethostbyname function returns a pointer to a hostent structure-a structure allocated by
>Windows Sockets. The hostent structure contains the results of a successful search for the
>host specified in the name parameter.
>The application must never attempt to modify this structure or to free any of its components.
>Furthermore, only one copy of this structure is allocated per thread, so the application should
　　　　　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> copy any information it needs before issuing any other Windows Sockets function calls.

162:デフォルトの名無しさん
05/12/25 13:57:38
struct hostent *host;
host = gethostbyname(argv[1]);

ってな形だし、どうみてもスレッドセーフでないと思ってた。
スレッド固有メモリなんてものでも使ってるのかな。

163:デフォルトの名無しさん
05/12/25 14:14:38
>>161
それだけでMT-Safeだとは限らない。

164:デフォルトの名無しさん
05/12/25 14:50:26
getaddrinfo ってのがあるんだ、
参考にしてた本が古っかったので知らなんだ。
該当箇所を書きかえねば orz

165:デフォルトの名無しさん
05/12/25 15:28:14
２ちゃんで書き込みするときの文字2048制限解除方法誰か教えてください。

166:デフォルトの名無しさん
05/12/25 15:29:18
制限解除して書き込んでる人が増えてるんですが

167:デフォルトの名無しさん
05/12/25 15:38:13
>>164
古いWindowsではありませんのでその辺は配慮を。

168:デフォルトの名無しさん
05/12/26 03:11:55
「スレッドできる」と「スレッドでファイル操作しても問題ない」は同義じゃないよなあ。
単一リソース操作は対策しないと普通は競合するよ。

169:デフォルトの名無しさん
05/12/26 19:09:27
マルチスレッドなサーバプログラムを作ってみようかと思ってます
クライアント数が少ない場合1クライアントに1スレッドを割り当てればいいかなと思いますが
クライアント数が多い場合はどういった方法が良いんでしょうか？
1スレッドあたりのクライアント数を決めてスレッドごとにselect()するとか
親スレッドでselect()して処理を別スレッドに任せるとか一応考えてはみていますが
どういった方法がスタンダードなんですかね？

170:デフォルトの名無しさん
05/12/26 20:42:42
ジョブキュー

171:デフォルトの名無しさん
05/12/26 22:37:27
+スレッドプール

172:デフォルトの名無しさん
05/12/26 23:38:08
裏技としてApache
勉強にはならんな・・・

次ページ