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

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

1:デフォルトの名無しさん
08/07/05 19:26:16
マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室その６
ｽﾚﾘﾝｸ(tech板)

■過去スレ
その１ URLﾘﾝｸ(pc3.2ch.net)
その２ｽﾚﾘﾝｸ(tech板)
その３ｽﾚﾘﾝｸ(tech板)
その４ｽﾚﾘﾝｸ(tech板)
その５ｽﾚﾘﾝｸ(tech板)

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

【ＯＳ】

【言語】

【実行環境】

【その他突起する事項】

2:デフォルトの名無しさん
08/07/05 19:31:40
■関連スレ・関連性の高いスレ

【マルチコア】並列化について語る【使いこなせ】
ｽﾚﾘﾝｸ(tech板)

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

ネットワークプログラミング相談室 Port21
ｽﾚﾘﾝｸ(tech板)

3:デフォルトの名無しさん
08/07/05 19:32:51
>>1-2
乙

4:デフォルトの名無しさん
08/07/07 12:40:51
これは関連スレじゃ無し？

OpenMPプログラミング
ｽﾚﾘﾝｸ(tech板)

5:デフォルトの名無しさん
08/07/07 12:50:44
じゃこれも

Message Passing Interface (MPI) 統合スレ
ｽﾚﾘﾝｸ(tech板)

6:デフォルトの名無しさん
08/07/09 20:28:14
boost::threadを使っていて質問があります。
スレッドオブジェクトをスレッド処理完了後に自動消去したいのですが、
以下のやり方だとまずい気がします。定石みたいなものはないでしょうか？

struct ThreadManager {
　boost::shared_ptr<Thread> th_; // 管理するスレッド
　bool thread_is_running(void) const { return th_!=0; }
　void start_thread(void) { if (thread_is_running()) return; th_.reset(new Thread(this)); boost::thread(boost::ref(*th_.get())); }
　// ※スレッド処理が終わったらth_を空にしたい
　void delete_thread(void) { thread.reset(); }
};

struct Thread {
　ThreadManager* p_;
　Thread(ThreadManager* p) : p_(p) {}
　void operator()(void) { /* ... スレッド処理 ... */ p_->delete_thread(); }
　// スレッド処理終了後、ThreadManagerを通じて自分を消去
};

7:デフォルトの名無しさん
08/07/09 21:11:24
boost::shared_ptr<Thread> th(new Thread);
boost::thread(boost::bind(&Thread::operator(), th));

8:6
08/07/09 22:44:08
7が動くのは理解したのですが、ありがたみがいまいちわかりません。
この場合thはスレッド処理が完了したこと（つまりth.reset()を呼ぶタイミング）を
どうやって知るのでしょうか。

9:デフォルトの名無しさん
08/07/09 23:01:53
いや…、どうやっても何もThreadのデストラクタが呼ばれるだろ。
ていうか何がしたいのさ？
スレッド作ってあとは関知せずという無責任なマネをしたいのか、
メインスレッドと同期して何かをしたいのか。

10:6
08/07/09 23:11:20
処理の種類に応じてThreadA、ThreadB、...（単一のThreadクラスを継承）を用意しています。
で、本体はThread*を1つ管理していて（p_とします）、
処理が必要になった時点でp_.reset(new ThreadA) のようにします。
その際に他のスレッドが処理中かどうかをp_!=0のように判定したいなと。

11:6
08/07/09 23:14:32
ありゃ、なんか>>10は>>6の単なる繰り返しですね…。
何をしたいかというと、いくつかのマルチスレッド処理を
排他でとっかえひっかえ行いたいという感じでしょうか。

12:デフォルトの名無しさん
08/07/09 23:23:24
まあ、普通に thread pool 使えばいいんじゃね。

13:13
08/07/09 23:36:47
教えてください。

A.cというファイルにグローバル定義で定義した
volatile変数をB.cというファイルで参照したい場合、

volatile extern int hoge;

とかでいいのでしょうか？

14:デフォルトの名無しさん
08/07/09 23:44:57
>>11
実行中のワーカスレッドが存在する場合にどういう選択肢があるのか
(終了を待ってから新しいスレッドを起動する/途中でも終わらせて新しいスレッドを起動する etc..)
によっても実装の仕方は変わってくると思うんだけど、どうだろう。

15:6
08/07/10 04:26:36
>>14
今のところ、実行中のワーカスレッドが存在する場合には、
「別のスレッドを実行中だからスレッド終了まで待ってね」
と表示して何もせずにreturnという仕様です。
（>>6の方法で動いてたのですが、たまたま運が良かっただけですね）

16:デフォルトの名無しさん
08/07/10 07:19:10
>>13
B.cでその前にstatic volatile int hoge;と書いてなければOK

>>7
これって、スレッド終了より早くthがスコープ抜けても問題ないの?
>>6がやりたいことはMFCのCWinThreadのbAutoDeleteでしょ。

17:デフォルトの名無しさん
08/07/10 23:17:00
>>16
shared_ptrでラップされてて、それを保持した
functorがスレッド終了時に破棄される。
そのタイミングでthの指すインスタンスも破棄される・・・・多分。

18:デフォルトの名無しさん
08/07/10 23:17:19
MFCは平気でdelete thisしてる。
ThreadManagerまで作ったのなら、()を直接呼び出すのでなくて
()を呼び出した後でメモリ解放するラッパーをサブスレッドで実行すればいい。
ついでにshared_ptrの操作前後で排他制御が必要。

19:デフォルトの名無しさん
08/07/12 00:29:11
タイムアウト監視中にシステム時刻が変更される可能性について
意識してない人が大杉な気がする。そういう脆弱なコードをいっぱい見てきた。
現実的な例として、ホストとの接続時に時刻の同期が要求される某FA分野プロトコルを
使ったシステムで、同時にハードとの通信のタイムアウトを監視してたら
とても愉快なことが起こり得るわけだ。
つまり、pthread_cond_timedwaitの仕様は困るってこと。
非標準の相対時間によるwaitをサポートしないPthread環境で
この問題を解決する方法が分からない、というかできないでFA?

20:デフォルトの名無しさん
08/07/12 01:17:00
放置！

21:デフォルトの名無しさん
08/07/12 03:25:52
ホスト時刻と端末時刻の差を管理すればいいだけじゃない

22:デフォルトの名無しさん
08/07/12 03:43:50
・時刻同期してから絶対時間に依存する処理を開始する
・時刻同期を徐々に（ntpd的に）行う

23:デフォルトの名無しさん
08/07/12 04:31:24
>>21 >>22
もしかしたら、俺がどうしてもUnixでシステムを動かす必要に迫られてると思って、
一生懸命解決策を考えてくれたんだろうか？だったらごめん。
Windows使ってます。

俺が知りたいのは、特定の仕様のシステムを実現する方法じゃなくて、
他のプログラムが何していようが、
ユーザが好き勝手に時刻を変更しようが、
現在からN秒以内に条件が成立しなければ、アウトという監視は本当にできないのかってこと。
Pthread標準の枠内で。
時刻をいじってるプログラムと密に連携したり同期とれるとか、
そんなこと当てにできないし、したくもない。

24:デフォルトの名無しさん
08/07/12 05:43:29
windowsでpthreadなの？よくわからんがTickCountじゃだめなのかな。

25:デフォルトの名無しさん
08/07/12 05:51:01
普通はハートビートを刻む液晶系のクロックと、カレンダ時計があって、
sleepだのwaitのタイムアウトの監視は前者、
カレンダ時計はcronのようなもっとスパンの長いスケジューラで使っていると思ったのだが、
pthread_cond_timedwaitはカレンダ時計を使ってるのかな。

26:デフォルトの名無しさん
08/07/12 06:50:42
pthread_cond_timedwaitは困ったことに絶対時間指定なんだ。
利用者にも実装者にも不評で
pthread以外の同種のAPIで待機時間でなく絶対時間を
使っているのは見たことがない。

27:デフォルトの名無しさん
08/07/12 09:49:47
まあAPI仕様に無い以上無理なんだろう。勉強になりますた。
苦しい対処だが1秒タイムアウトをN回繰り返せば誤差1秒でタイムアウトできる、かな。
あとWindowsならスレッド生成だけpthread使って、同期はWin32 APIでするとか

28:デフォルトの名無しさん
08/07/12 10:48:39
情報小出し君にはレスしても無駄だと分かった

29:デフォルトの名無しさん
08/07/12 10:57:06
>>27
Windows で pthread ?

なんでそんなことしたいのかを書かないと、単なるバカにしか見えないよ。

あと、pthread_cond_timedwait がダメダメなら、setitimer でシグナル
もらうとかすればいいんじゃないのか？

30:デフォルトの名無しさん
08/07/12 11:09:52
URLﾘﾝｸ(sourceware.org)　のソースを確認したのだが、
絶対時間をすぐさま待機時間（ミリ秒）に変換。
最終的にWaitForMultiObjectのtimeout指定で使ってた。

31:デフォルトの名無しさん
08/07/12 11:12:15
Win32と言ったりpthreadと言ったり、答えようがない。
Win32には延長付のタイムアウトのAPIや時刻に影響しない経過時間を計測できるAPIがあるのに残念だったな。

32:27
08/07/12 11:18:17
>>29
俺は>>27だが、>>19=>>23とは別人だ。
もともとの>>19がWindowsでpthreadのようだけど、企業でそういう指定があるから
だと推測した。それで「使ってるフリして回避する方法」として、同期だけWin32したら?
と言ってみた。

33:19
08/07/12 13:00:21
>>19=>>23だが、なんか混乱させてるな。
俺が現実に直面してる仕事なんかに関係なく、
このpthread_timedwaitの仕様どうなの？って話がしたかっただけ。
俺でも分かるような欠陥が本当にメジャーな標準規格にあるのか
疑問だったので、もしかしたら、今のPthreadの枠内で簡単に解決する方法があるのかと思った。
それも聞きたかったことの一つ。
Pthread本を見ると、絶対時刻が使われていることのメリットしか書かれてないけど、
俺としては、相対時刻でタイムアウト監視できるAPIの方がよほど必須のように思えたので。

34:デフォルトの名無しさん
08/07/12 14:15:09
tasksetの使い方教えてください。オプションとか…。
　スレッド１→コア１
　　　　　…
　スレッド４→コア４
みたいに割り当てたいのですが、
tasksetじゃできないですかね…？
ちなみにlinuxでopenmpでやろうかと思っています

35:デフォルトの名無しさん
08/07/12 14:21:58
で、このスレとしてはPthreadではできないという結論になると。
>>26 C++ boostも絶対時間だったような。

36:デフォルトの名無しさん
08/07/12 14:36:44
>>34
そうしたい理由を先に言ったほうがいいよ
まさか
「割り当てられないとしたらその仕様どうなの？って話がしたかっただけ」
じゃないよな

37:デフォルトの名無しさん
08/07/12 14:51:09
>>35
最新版ではabstimeとreltime向けに別々の時間クラスが定義されて
timedwaitはオーバーロードされてる。
例によって、実装はテキトーに変換してるだけなので、
ネイティブに近い方のオーバーロードだけは信頼できるってかんじかな。

38:デフォルトの名無しさん
08/07/12 15:29:11
>>37
信頼できるかどうかはOS次第だと思う。
どんなラッパー仕様だろうと最終的にはOSのAPIを呼び出すことになるので
>>30は当然のこと。もしPthreadのプログラムインターフェースしか提供されて
いないOSなら信頼はできない。

39:デフォルトの名無しさん
08/07/13 02:16:06
ｽﾚﾘﾝｸ(unix板:69番)

笑った

40:デフォルトの名無しさん
08/07/13 03:48:14
>>19はPthreadの絶対時間指定によるデメリットを仕様欠陥と(あちこちで)指摘してるだけだろ。
一貫してるからいいんじゃね?
例がアレなので相手にされてないようだけど「システム時刻を修正されるとまずい」ってのは
事実で、時間が巻き戻らない前提ってのは無茶苦茶だ。SIベンダがBtoBで構築するシステムなら
ともかくフリーソフト作れねーぞ。

しかも理由が「絶対-相対の変換の足し算中にプリエンプションが発生すると待ち時間がずれる
から」ってのは納得できねー。タイムアウト時間にごく僅かな誤差が出ることに問題あるとは
思えないし、責任をアプリに押しつけただけなのは基盤として問題だろ

41:デフォルトの名無しさん
08/07/13 05:49:24
>>19は>>23の書き込みが余計だったな、誤解を招いた。
続けるなら>>39のUNIX板のがいいじゃないか。

42:デフォルトの名無しさん
08/07/13 15:02:30
>>40
え～っと、本人乙でいいかな。

43:デフォルトの名無しさん
08/07/13 23:27:07
マルチスレッド対応にしたら
デュアルコアのCPUを両方とも使って処理してくれるの？

44:デフォルトの名無しさん
08/07/13 23:33:38
>>43
普通はOSまかせ。
OSはコアをまんべんなく使おうとするから普通は両方使ってくれるが、
他のプログラムが１つのコアをめいいっぱい使ってたら、
同じコアに振られることもある。

45:デフォルトの名無しさん
08/07/15 08:20:00
ｻﾝｸｽ

46:デフォルトの名無しさん
08/07/17 01:20:09
自演乙

47:デフォルトの名無しさん
08/07/17 02:11:04
自演乙厨ｗ

48:デフォルトの名無しさん
08/07/18 00:32:11
void f()
{
static struct Hoge hoge;

pthread_mutex_lock();
///hogeにアクセス
pthread_mutex_unlock();
}

こんな感じのコードあってstaticだから安全だって譲らない
Ｋ主任って糞がいます助けてください

49:デフォルトの名無しさん
08/07/18 01:00:04
Hogeがコンストラクタを持つの？

50:デフォルトの名無しさん
08/07/18 01:01:55
>>49
Ｃ99ですＣ＋＋じゃないです

51:デフォルトの名無しさん
08/07/18 01:11:21
K主任も災難だな

52:デフォルトの名無しさん
08/07/18 01:17:01
>>48
どういう危険があると思うの？

53:デフォルトの名無しさん
08/07/18 02:50:08
>>48
少なくともそこで示されている記述だけじゃ
問題のあるソースだとは思えん。

pthread_mutex_lock()とかの引数に渡されているmutexが
非staticなauto変数とかだったらダメだけど。

54:デフォルトの名無しさん
08/07/18 14:39:31
hogeのアドレスを外部に漏らして、そっちはmutexなしでアクセスとか?

55:デフォルトの名無しさん
08/07/19 17:07:42
安全って理由が staticだからでmutexはあってもなくても関係ないって
K主任が主張してあるのであれば、これはもうどうしようもない

56:デフォルトの名無しさん
08/07/19 17:19:44
ワロタ

57:デフォルトの名無しさん
08/07/19 18:39:06
つまりこういうこと？

>>48って糞が粘着しています助けてください　　Ｋ主任

58:デフォルトの名無しさん
08/07/19 20:42:06
>>48
どんな危険があると考えてるのな？
hogeのポインタを外に出さない限りmutexはいらないと思うけど。

59:デフォルトの名無しさん
08/07/19 21:04:23
>>58
fが複数スレッドから呼ばれるとしたら、hogeをどうするのかによるね。

60:デフォルトの名無しさん
08/07/19 21:11:22
>>59
複数スレッドで呼ぶとどうなるのでつか？

61:デフォルトの名無しさん
08/07/19 22:46:35
Ｋ主任が見てるようなので退散します・・・

62:デフォルトの名無しさん
08/07/20 02:19:01
strtokとstrtok_rの違いを考えろ

63:デフォルトの名無しさん
08/07/20 03:51:23
ネタを振った責任として>>48は、何が問題があると思うのかくらいは
説明して欲しいな。

64:デフォルトの名無しさん
08/07/20 08:50:23
>>63
Ｋ主任の糞っぷりです

65:デフォルトの名無しさん
08/07/20 16:35:37
>>60
hoge がstaticだから、hogeのコンストラクタが（あれば）起動時
一度だけ動くのみ。
だから排他部分の外で宣言されていても安全、ってことだろう。

とはいえstaticじゃ無かったとしても何か危険があるかというと
よくわからんから、staticだから安全ってのはなんか変な主張
という気がしなくもないな。

66:デフォルトの名無しさん
08/07/20 16:54:53
アドレスを外部に漏らしてなければ、この関数からしか
アクセスできない。そこに排他がちゃんとかかってるか
ら大丈夫だろ？って言うことだと思うが。

67:デフォルトの名無しさん
08/07/20 17:24:19
C99って言ってるから(>>50)コンストラクタはないんだが、
仮にc++だとすると

>>65
>hoge がstaticだから、hogeのコンストラクタが（あれば）起動時
>一度だけ動くのみ。

違うぞ。
static struct Hoge hoge; の行に到達したときに、
一度だけ実行される。
その「一度だけ」のフラグが排他されていないことがあるだろう、
というのが起こりうる問題。

68:デフォルトの名無しさん
08/07/20 17:59:36
仮にC++だとするとこうするべきってことですか？
pthread_mutex_lock();　
static　struct　Hoge　hoge;　
///hogeにアクセス　
pthread_mutex_unlock();　

69:デフォルトの名無しさん
08/07/20 18:08:21
前スレ850くらいからその話題が出てるわけで

70:デフォルトの名無しさん
08/07/20 19:39:41
DCLでいいよ。

71:デフォルトの名無しさん
08/07/20 22:49:34
そこで-fthreadsafe-statics

72:デフォルトの名無しさん
08/07/20 23:29:57
そんな実装依存じゃＫ主任に笑われるぞ

73:デフォルトの名無しさん
08/07/29 08:24:43
ハードのことはよく分からないのですが、同じメモリアドレスに複数のコアが同時アクセスすると
なにか問題が起こることはあるのでしょうか？

例えば整数型のグローバル変数aを作り、
スレッド1ではそれを読みこみ加算します。スレッド2ではそれを読み込み減算します。
シングルコアでは物理的に、本当の意味での同時アクセスはありえないので
意図した結果が得られないとしても、ハード的に不具合はないですよね。
仮にスレッド1ではreadのみ、スレッド2ではwriteのみだと何の問題もないはずです。

これがマルチコア環境だと、スレッド1がread, スレッド2がwriteのみだとしても
同メモリアドレスに各コアが本当の意味で同時アクセスしますよね。
こういうことはやってはいけないのでしょうか？

74:デフォルトの名無しさん
08/07/29 08:44:31
いや、同時アクセスしてもハード的な問題は起きない
writeの結果がreadに反映されるかされないかの問題でしかない

75:デフォルトの名無しさん
08/07/29 11:26:02
>>73
それが同じCPU内の別のコアなら、キャッシュ管理かどっかで調停するから問題ない。
それが違うCPUのコアなら、メモリ管理かどっかで調停(ｒｙ

76:デフォルトの名無しさん
08/07/29 11:35:00
コア毎のキャッシュにヒットしなかったと仮定すると、
最終的に、競合するバスアクセスが発生するわけだが、
その時にはバスのアービタが調停する。

77:デフォルトの名無しさん
08/07/29 16:34:22
>>74-76
ありがとうございます。
調停(アービトレーション？)というのは調べても詳しくは分からなかったのですが、
同時アクセスするような状況で排他処理をしてくれるということでしょうか

78:デフォルトの名無しさん
08/07/29 16:38:24
ハード的な話なのでソフト的な排他処理とはちょっと違う希ガス。

79:デフォルトの名無しさん
08/07/31 02:06:51
ハード屋の無知はおいておくとして、信用するなよ。

マルチコアとシングルコアの違いは、スケジューラを動かす数が
違うのが一番大きい。あるスレッド（プロセス）は、基本的に１つの
CPU上で動作する。

当然、複数のスレッド（プロセス）間の排他は必要だが、アプリ上
はたいして変わらない。マルチコアでは、アトミックな操作のための
バスを占有するような命令が追加されているだけ。

80:デフォルトの名無しさん
08/08/01 12:45:08
>マルチコアとシングルコアの違いは、スケジューラを動かす数が違うのが一番大きい。
誰もそんな話してないしｗ
>あるスレッド（プロセス）は、基本的に１つの CPU上で動作する。
間違ってるし

ロードバランスとか考え出すと頭が痛くなるが，まぁ
Read-Write-lock みたいなことをやってると思っとけば

81:デフォルトの名無しさん
08/08/02 14:33:08
基本的にって言ってるから何でもあり。

82:デフォルトの名無しさん
08/08/02 18:46:05
て言うかある一瞬を言ってるのか、スレッドの一生を言ってるのかわからんから
間違ってるか判断できない。

83:デフォルトの名無しさん
08/08/03 00:19:01
突っ込み所が違うだろ。
>>73に対して>>74～>>76が問題ないって言ってるのにそれを否定してるんだぞ。
メモリの同時アクセスは複数プロセスでも起こるので、すべてのメモリアクセスは
明示的にバスの排他命令を使用する必要があるな。

84:デフォルトの名無しさん
08/08/03 00:39:01
>77はこれでも読んでみれ
Wikipedia項目ﾘﾝｸ

85:デフォルトの名無しさん
08/08/03 00:49:09
>>79 の書き込みは、肝心なところがちゃんと書いてないから
正しいとか間違ってるとか言うことはできない。

まあ、>83 の書き込みも似たようなものだが。

86:デフォルトの名無しさん
08/08/24 23:25:42
RT-Linuxでマルチスレッドで組んでいます。
スケジューリングポリシーはSCHED_FIFOです。

pthread_condを使った排他を考えているのですが、
pthrad_cond_wait()を複数スレッドで呼び出した後に
pthrad_cond_broadcast()を呼び出した時の動き出すスレッドの
順番がスレッドの優先度順になっていません。
(ちなみにsunのページにはブロック解除の順番は不定と書いてありました。)

そもそもやりたい事が
URLﾘﾝｸ(www.hanecci.com)
の「リードライトロック」のような事なのですが、
優先度順に動き出させるようにするにはどうしたらいいですか？

よろしくおねがいします。

87:デフォルトの名無しさん
08/08/24 23:59:16
写生してえ。

88:デフォルトの名無しさん
08/08/25 01:57:04
だから、スケジューラの実装依存になるようなプログラムを組むなと
なんど言ったらわかるのだ・・・。マイナーバージョンが変わっても、
挙動かわるぞ。

89:デフォルトの名無しさん
08/08/25 02:19:03
何のためのRT-Linux

90:デフォルトの名無しさん
08/08/25 21:28:31
>>86
pthread_cond_waitに入るときに、クリティカルセクション内で
現在待ちに入っているスレッドの優先度をメモっておいて、
pthread_cond_broadcastで起きたときに、クリティカルセクション内で
自分より高い優先度のスレッドが待ちに入っているなら、
何もせずに再びpthread_cond_waitに入る、じゃだめなのかな。

必ずその優先度の高いスレッドも起こされるはず・・・だと思う。
やばいタイミングとかあるか・・・な？

91:デフォルトの名無しさん
08/08/25 21:48:00
CPU稼働率落ちそうだな。

92:86
08/08/25 22:44:47
解決した。
pthread_condとかつかわずにセマフォで普通に組めるのね。

ありがと。

>>87
うん

>>88、89
そこでヒントがほしかった＞＜

>>90
簡単な仕組みにしたいっすね。

>>91
ですね

93:デフォルトの名無しさん
08/08/25 23:33:52
簡単にCreateThreadできるようになるクラスとかないかな

94:デフォルトの名無しさん
08/08/25 23:43:39
boost::threadとか？

95:デフォルトの名無しさん
08/09/09 15:11:50
データ処理部分とHDDから読み込み&書き込み処理部分ってスレッド分けた方が効率上がると思うんですが、
HDDのIO部分自体は分けないで一つのスレッドでやった方が効率いいですよね？
2つの異なるHDDから読み込み＆書き込みする場合はHDD毎にスレッド作った方が効率いいですよね？
間違ってたら指摘お願いしますm(_ _)m

96:デフォルトの名無しさん
08/09/09 15:21:44
>>95
ドライバはカーネルが動かす。従って、CPUが複数(或いは複数コア)あるなら
ユーザアプリとは並列に動ける。おまけに、ディスク自体にもバッファがあるから普通は余り意識しない。
まして一般的にディスクの方が圧倒的に遅いから、HDD毎にスレッドを作るなんて事はしない。

97:デフォルトの名無しさん
08/09/09 15:23:45
追記です。二つ目の質問は
「一つのHDDから複数のデータを読み書きするとき、データごとに別スレッドにはしないべきか」と言う意味です
宜しくお願いします

98:デフォルトの名無しさん
08/09/09 15:33:43
HDDは遅いから複数スレッドの方がいい
HDD1が終わるまで待っている時間が無駄

99:デフォルトの名無しさん
08/09/09 15:38:58
早速回答ありがとうございます！
しかし>>96と>>98の言っていることが逆に見えて混乱しています

たとえカーネルが実際のIO等を行ってるとしても、読み込み終わるまでアプリは待機しますよね？
IO毎にスレッドを分ければその間CPUはアイドル状態にならずに効率が上がるかと思うのですが・・・

しかし、同じHDDで読み書きするデータごとにスレッドを分けるのは流石にやりすぎですよね＾＾；

100:デフォルトの名無しさん
08/09/09 15:43:03
>>99
>95はI/Oに限定した話じゃないの? I/Oしかやることがないならスレッド分けたって待つだけじゃん。
処理とI/Oを分けるかって話なら処理がI/Oに依存しないで済むなら分けておいたら? ってことになる。

101:デフォルトの名無しさん
08/09/09 15:47:51
一番初めに
「データ処理部分とHDDから読み込み&書き込み処理部分ってスレッド分けた方が」
って書いてあるだろ

102:デフォルトの名無しさん
08/09/09 16:22:13
>>100
ありがとうございます。処理とIOを分けたかったんです。
処理とIOは依存しないわけではないのですが、パイプライン式に順次並列処理しようかと思います。

103:デフォルトの名無しさん
08/09/09 16:33:02
読みながら処理しながら書くの？
読んでから処理してから書くの？
読みながら処理してから書くの？

104:デフォルトの名無しさん
08/09/09 17:26:37
こんな感じで実行予定です
以下同行は並列と見てください

HDD1からDATA1読み込み
HDD1からDATA2読み込み　　DATA1の処理
HDD1からDATA3読み込み　　DATA2の処理　　HDD2にDATA1書き込み
HDD1からDATA4読み込み　　DATA3の処理　　HDD2にDATA2書き込み
　　　　　　　　　　　　　　　　　　　DATA4の処理　　HDD2にDATA3書き込み
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　HDD2にDATA4書き込み

105:デフォルトの名無しさん
08/09/09 17:46:11
マルチスレッドなんて使わずに非同期入出力で

106:デフォルトの名無しさん
08/09/09 18:30:45
非同期でOSまかせが速い、効率いいとはいえない。
データをまとめて出力するなどキャッシュを作った方が速い。
10Kを一万回やったら非同期でも時間かかる

107:デフォルトの名無しさん
08/09/10 09:47:23
読み込んだデータをクラスに展開しないといけないので、非同期読み込みだと
メモリを最悪倍近く無駄に食うような気がしたのでこの方法がいいかと思ったのですが・・・

また、細切れに読み込んでも連続したデータであればキャッシュは効くと聞いたことが
あるんですがそれも違うのでしょうか？

108:デフォルトの名無しさん
08/09/11 04:25:04
先読みに頼るぐらいならまとめて読め

109:デフォルトの名無しさん
08/09/11 17:42:38
>>107
win32なら、ファイルを開くときのオプションでキャッシュに連続の先読みを指示するオプションがある。
基本的にAPIの呼び出し回数を減らすのが速い

110:デフォルトの名無しさん
08/09/12 15:57:55
並列動作で効率を高めるため、最適な数のスレッドを生成したいのですが
コア数を取得するAPIが見つからなくて困っています。API等では用意されていないのでしょうか

111:デフォルトの名無しさん
08/09/12 16:07:37
なんのことはない，Win32の　GetSystemInfo()　を叩けばいいらしい
SYSTEM_INFO構造体を受け取って
dwNumberOfProcessorsメンバーにコア数が入っているとのこと
URLﾘﾝｸ(gurizuri0505.halfmoon.jp)

112:デフォルトの名無しさん
08/09/12 16:09:23
URLﾘﾝｸ(www.usefullcode.net)

113:デフォルトの名無しさん
08/09/12 16:48:59
即レスさんくす！
無事取得できましたm(_ _)m

114:デフォルトの名無しさん
08/09/13 04:35:56
タスクマネージャのパフォーマンスグラフみたいに、
コア毎の負荷(使用率)を知りたいのですが、
簡単に取得する方法はありますか？

115:デフォルトの名無しさん
08/09/13 09:40:30
環境次第

116:デフォルトの名無しさん
08/09/20 10:59:05
マルチスレッド用の効率的なQueueを書いてください

117:デフォルトの名無しさん
08/09/20 11:53:09
状態変数の練習にはいいんじゃね

118:デフォルトの名無しさん
08/09/20 11:59:21
lock free queue

119:デフォルトの名無しさん
08/09/20 12:28:10
プライオリティキューを
マルチスレッド化したいです

120:デフォルトの名無しさん
08/09/20 15:09:44
pthread_cond_wait()が遅くて
しょりがおいつかないときって
大体方法何かないですか
たすけて～～～

121:デフォルトの名無しさん
08/09/20 15:32:57
どうやって遅いって調べたんだ

つかwaitしてるようで実はポーリングになってるとかいうオチじゃなかろうな

122:デフォルトの名無しさん
08/09/22 09:07:18
私たちはマルチスレッドですか？

123:デフォルトの名無しさん
08/09/22 09:19:12
>>122
精子はマルチで卵子に向かいますが
卵子は基本的には一匹入ったらLockをかけるので
通常はシングルで動きます
でも、時々Lockに失敗して双子以上ができる場合があるので注意が必要です

124:デフォルトの名無しさん
08/09/22 09:53:22
マルチスレッドと言うより、
イベントドリブンというか、割り込み駆動な感じだな。

125:デフォルトの名無しさん
08/09/22 12:27:29
NMI最強

126:デフォルトの名無しさん
08/09/22 15:54:58
今日のわたしはモード２なのよ
URLﾘﾝｸ(www.youtube.com)

127:デフォルトの名無しさん
08/10/05 11:44:01
複数スレッドのプログラムへのCPUコアの対応としては>>44とのことですが、
コア数を設定できるソフトの場合、4コアCPUなので4コアを設定したとしても
OSが状況に応じてそれより少ないコアで処理させてり、というようなことが
起こってしまうのでしょうか？

128:デフォルトの名無しさん
08/10/05 12:05:42
>>127
ユーザープログラムを4コア設定にしようと
OSが割り当ててくれないかぎり無駄。

129:127
08/10/05 12:10:42
>>128
なるほど･･･
いちおう4コアとか設定はできるものの、それは「4スレッド以上使うプログラムで実行しますよ」ということであって、
OSによりコアに手空きがあれば初めて実現することなんですね。
勉強になりました。
そうすると「このプログラムは2コアまで対応してるからCPUは2コアのものを購入」となるところを、余裕を見て
4コアCPUにしておく、という考え方が有効になるわけですね。
勉強になりました。
ありがとうございました。

130:デフォルトの名無しさん
08/10/05 17:18:13
有効ってまあ有効と言えば有効だけどあまり有効って感じじゃない。

131:デフォルトの名無しさん
08/10/05 21:55:34
裏で200も300もスレッド走ってなきゃ
２コアでも４コアでも指定したスレッド起こせるだろw

その実装がスケール可能かつ性能どれだけ伸びるか考えろよw

132:デフォルトの名無しさん
08/10/06 11:30:00
余り細かい話になると、OSとCPUを特定しないと意味がなくなる気がするのだが。
因みにLinuxの場合、Gnomeが、ひいてはXが動いているとそれだけで1コア占有するくらいパフォーマンスが落ちることもあるので注意。
# 今時、それほど酷くないけどね。

133:デフォルトの名無しさん
08/10/06 22:25:18
>>132
それこそKernelとGnomeのバージョン言えって
話だけどな

134:デフォルトの名無しさん
08/11/03 14:53:14
pthread に、スレッドが pthread_cond_wait で待ち状態にあるかを判定する関数はありますか？

135:デフォルトの名無しさん
08/11/03 14:56:13
pthread に、スレッドが pthread_cond_wait で待ち状態にあるかを判定する関数はありますか？

136:デフォルトの名無しさん
08/11/03 15:03:28
２回書き込んでしまった。すんません。

137:デフォルトの名無しさん
08/11/03 15:11:31
大事なことだからしょうがない

138:デフォルトの名無しさん
08/11/03 15:20:31
大事なことだからしょうがない

139:デフォルトの名無しさん
08/11/03 15:27:32
して、待ち状態は判定できるんですか？

140:デフォルトの名無しさん
08/11/03 15:58:00
A.問い合わせる

B.返事来る

C.返事が甲なので甲とみなした処理をする

んでB～Cの間に乙になってて発狂する予感

141:デフォルトの名無しさん
08/11/03 21:35:35
>>135
wait状態を取得する関数があったとしても、現在もその状態である保障は無いね。

142:デフォルトの名無しさん
08/11/04 12:19:49
状態を取得した一瞬後には状態が変わってるかもしれんしな

143:デフォルトの名無しさん
08/11/04 12:52:40
pthread_cond_waitの引数のmutexを使えばできそうな。
pthread_mutex_trylockでmutexがロックできたらwait中。

144:デフォルトの名無しさん
08/11/05 00:02:01
トランザクションメモリの実装について
くわし～～くかいた本ある？

145:デフォルトの名無しさん
08/11/05 01:02:19
>>144
「Transactional Memory」
くわし～～くはないがたくさんは載ってる

146:デフォルトの名無しさん
08/11/06 00:02:30
>>143 wakeupしたあとにCPUがまわってくるのを待ってる状態という場合もある

147:デフォルトの名無しさん
08/11/09 01:48:11
デバイスとの非同期処理の為に、別スレッドでポーリングしているんだが、
ポーリング関数内で、select -> read の処理を丸ごとロックしてる。
書き込みはメインスレッド内でロックして write 。

一応動いてるんだけど、どうも自信がない。
間違って select なりmutex なりを使っている気がする。
こういう類いの処理ってどういう本読めばいいのかな。
何かアドバイスください。

148:デフォルトの名無しさん
08/11/09 11:21:59
それだと、ポーリング用スレッドがselect+readでロックしている間、
メインスレッドがロックを獲得できない(writeできない)気がするがどうか。

select実行中のロックは不要だろう。
ただselect用のFD_SET作成中はロックがいる気がする。

みたいな。

149:デフォルトの名無しさん
08/11/09 16:25:47
>>147
情報が少なくてよくわからないけど、とどのつまり、何のために
ロックしなくちゃいけないかってこと次第

read と write が同時に発行できるならロック不要だし、
同時に出来ないなら、そのルールに合わせてロック入れる。

あと、多分、 select　は不要なんじゃないかね

150:デフォルトの名無しさん
08/11/09 16:46:16
関数型言語だと具体的にどういう風にマルチスレッドに最適なの？
去年あたりからErlangとかScalaとかHaskellとかが話題になってて気になる。
全ての関数がワーカスレッドベースになるとかそんなとんでも話じゃないよね？

151:デフォルトの名無しさん
08/11/09 17:42:57
STM難しい
やる夫助けてくれ

152:デフォルトの名無しさん
08/11/09 18:05:32
>>150
第五世代コンピュータでヤフれ

153:デフォルトの名無しさん
08/11/09 20:00:16
すみません。言語としてWinAPI(C言語）、C#、Javaを覚えたのですが（どれもGUIやファイル操作、DB接続ができる程度のレベルです。あとネットワークも少々）
スレッドプログラムを次はマスターしたいのですが、どの言語でスレッドを学ぶのが一番いいですか？

ひとつ覚えたら残りの言語も覚えたいと思っていますので、とっかかりに一番いいのをおしえてください。
よろしくお願いします。

154:デフォルトの名無しさん
08/11/09 20:11:20
Java

155:デフォルトの名無しさん
08/11/09 20:29:50
>>153
どれでもいいよ。そんな取り立てて挙げるほど大層なもんじゃない。

156:デフォルトの名無しさん
08/11/09 20:52:34
まぁJavaかC#だな。C言語でやるとLockが面倒だし

157:デフォルトの名無しさん
08/11/09 22:39:47
だね。
スレッドに絡む部分、概念の学習に専念できるという意味でも、
JavaかC#辺りがやりやすいと思う。

158:デフォルトの名無しさん
08/11/09 22:42:28
良書が揃ってるのはJavaだからJavaにしとけばいいと思うよ

159:153
08/11/09 23:06:46
みなさんどうもありがとうございます。>>156さん、WinAPIでやるとちょっと面倒なんですね。
なるべく単純な概念だけを覚えたいので、C#かJavaにしようとおもいます。

でも、>>154サン以降全員Javaが候補に入ってるのでJavaにしようとおもいます。
いまから、本屋にいって立ち読みしてきたいとおみます。みなさん、ありがとうございました。

念願のスレッドプログラムの第一歩を踏み込めそうです。

160:デフォルトの名無しさん
08/11/10 11:33:47
ところでおまいらhyukiの
『Java言語で学ぶデザインパターン入門マルチスレッド編』
っておすすめでしょうか？

161:デフォルトの名無しさん
08/11/10 11:45:24
Java固有の話とそうでない話を見分けるつもりで読むといいよ

162:デフォルトの名無しさん
08/11/10 12:08:45
並行プログラムの本がある、おすすめ。

163:デフォルトの名無しさん
08/11/10 17:09:52
>>160
入門書としてはベスト。それ卒業したら「Java並行処理プログラミング」

164:デフォルトの名無しさん
08/11/10 18:30:24
JavaってマルチCPUなりコアなりの環境でもシングルCPUしか使えない
と認識してるけどあってる？

165:デフォルトの名無しさん
08/11/10 18:31:56
あってる
グリーンスレッドっていう環境にやさしいスレッド方式があって、
デフォルトはそれになってる

166:デフォルトの名無しさん
08/11/10 18:46:24
グリーンスレッドなのはjavaの最初の版だけだったと記憶してるけど、
今でも切り替えられたっけ？

167:デフォルトの名無しさん
08/11/10 19:23:04
>>165
十年前から乙。
>>166
無理。グリーンスレッドとネイティブスレッドの切り替えがあるのはClassicVMで、HotspotVMはネイティブスレッドのみ。
で、ClassicVMはJava1.4あたりで切られたようだ。

168:デフォルトの名無しさん
08/11/10 21:01:28
1.2 ぐらいまではずっとグリーンスレッドだった。
最初の版だけなんてことはない。

169:デフォルトの名無しさん
08/11/10 23:05:10
WroxのProfessional Multicore Programming
ってCore2とかAMDのCPUのことも書いてあるんだな

170:デフォルトの名無しさん
08/11/11 00:42:41
URLﾘﾝｸ(pc.watch.impress.co.jp)

これをうまく制御するプログラミングが知りたい

171:デフォルトの名無しさん
08/11/11 00:48:22
>>170
Intelのパフォーマンスライブラリに期待しよう

172:デフォルトの名無しさん
08/11/11 10:48:50
>>170
すげー
ビリー・ミリガンみてーだな

173:デフォルトの名無しさん
08/11/12 04:44:45
>>170
元気なプロセスをいっぱい動かせば良いだけのような気もする。

174:デフォルトの名無しさん
08/11/12 07:02:25
同じアドレスに一斉に読み書きするとか
同じロックを一斉に取得、解放するとか
そういうループをブン回して
どうなるか観察したい

175:デフォルトの名無しさん
08/11/13 00:36:35
>>170
スレッドを192個作る。
各スレッドのaffinityを設定して、CPUに貼り付ける。
特定のスレッドのセットをビジーループにして、タスクマネージャに文字を出す。

176:デフォルトの名無しさん
08/11/13 00:47:04
>>175
> 特定のスレッドのセットをビジーループにして、タスクマネージャに文字を出す。

ビルのイルミネーションみたいでいいね！

177:デフォルトの名無しさん
08/11/13 09:57:17
winで1プロセスに64コア以上ってどうやるんだっけか

178:デフォルトの名無しさん
08/11/17 20:48:06
>>177
>Windows 7/Windows Server 2008 R2 では 64 論理 CPU をひとつの "グループ" と定義し，
>プロセスは初期状態で "グループ" のどれかに束縛されている(どのグループに属するかはラウンドロビンで決定される)．
>そして，新しく定義された API で明示的に許可を与えない限り，プロセス内のスレッドは
>所属 "グループ" の CPU でのみ実行される．

>つまり，新しい CPU グループ制御 API を使用しない限り，ひとつのプロセスは高々 64 個の
>プロセッサしか活用しない．

URLﾘﾝｸ(d.hatena.ne.jp)

179:デフォルトの名無しさん
08/11/18 11:06:48
窓7が主流になる頃には64コアCPUとか出てるって事？
凄いな

180:デフォルトの名無しさん
08/11/18 11:14:12
マルチCPU

181:デフォルトの名無しさん
08/11/18 11:30:11
8コア*8CPUでやっと64
4CPUのマザーは見たことあるけど…

182:デフォルトの名無しさん
08/11/18 13:20:57
ブレードにすればよかろう。

183:デフォルトの名無しさん
08/11/18 22:01:52
コンシューマ向けの話じゃないのか

184:デフォルトの名無しさん
08/11/19 00:25:44
て言うか、ブレードってブレード毎にＯＳが載ると思うが。
８ブレードとかを１つのＯＳで制御できる奴なんてあるのか？

185:デフォルトの名無しさん
08/11/19 00:37:32
>>184
URLﾘﾝｸ(www.hitachi.co.jp)
インテル Itanium プロセッサー搭載サーバブレードでは、バックプレーンの
高速インターコネクトを介し最大4枚のサーバブレードをSMP接続することで、
最大8プロセッサ（16コア）のSMPサーバーとしても利用可能。

URLﾘﾝｸ(h50146.www5.hp.com)
最新のデュアルコアインテル Itanium プロセッサ（9100シリーズ）を最大4,080個搭載可能

186:デフォルトの名無しさん
08/11/19 07:36:32
>>185
これ買おうかな
やっぱ自宅警備にはこれくらいのマシンがないとな

187:デフォルトの名無しさん
08/11/20 17:32:02
int　i;
for(　i=0;　i<10;　i++　)
{
　　h　=　CreateThread　(　NULL,　0,　(LPTHREAD_START_ROUTINE)DoIt,　NULL,　0,　&id　);
}

void　WINAPI　DoIt()
{
　　//　ここでいろいろ
}

のようにして同じ関数を複数のスレッドで行いたいのですが
ここでいろいろのところに制御がいかず　すぐにスレッドが終了するのですが
同じ関数をスレッドで実行することはできないのでしょうか？

WindowsXP
C/C++　Win32API

188:デフォルトの名無しさん
08/11/20 17:47:14
>>187
まず先に突っ込んでおくが、LPTHREAD_START_ROUTINEと
合わない関数をキャストで無理矢理渡すな。
DoIt()がLPTHREAD_START_ROUTINEに適合する関数なら
キャストなんて必要ない。

すぐにスレッドが終了するってのは、どうやって確認した？
CreateThreadを呼んだメインスレッドは、各スレッドが仕事を
終えるまで待機している？
そもそもDoIt()がすぐに終了する内容じゃないの？

189:デフォルトの名無しさん
08/11/20 18:09:42
>>188
すいません
処理の流れがつかめてませんでした

解決しました

190:デフォルトの名無しさん
08/11/20 18:18:19
便乗して質問ですが
WindowsXP　Home　Edition　にて作成するスレッド数の上限はありますか？

191:デフォルトの名無しさん
08/11/20 18:26:58
URLﾘﾝｸ(msdn.microsoft.com)
> 1 つのプロセスが作成できるスレッドの数は、利用可能な仮想メモリによって制限されます。
> 既定では、各スレッドに 1MB のスタック空間が割り当てられています。
> そのため、最大 2,028 個のスレッドを作成できます。

192:デフォルトの名無しさん
08/11/20 19:35:05
マルチもいいけど　実行ファイルが自分で空いてるCPU選ぶようにしたい
Windows側でプロセス作成時に勝手にやってるとありがたい

193:デフォルトの名無しさん
08/11/20 21:55:25
意味がわからん。
スレッドはあいているCPUでしか実行出来ないし。

ひょっとして、自分のプロセス専用にCPUが
割り振られて欲しいって話か？

194:デフォルトの名無しさん
08/11/21 10:58:32
Sleep関数について質問ですが

MSDNによると
VOID　Sleep(
　　DWORD　dwMilliseconds　　　//　中断の時間
);
とありますが
マイナスの値を代入した時の挙動はどうなるのでしょうか？

実際ためしてみたのですが、永遠制御が返ってきません

195:デフォルトの名無しさん
08/11/21 11:34:10
DWORDは符号なしの型だからマイナス値を取れないと思うが

196:デフォルトの名無しさん
08/11/21 11:39:26
>>195
なるほど

しかし、VC++6.0　では怒られないんですよ
URLﾘﾝｸ(2ch.homelinux.com)

197:デフォルトの名無しさん
08/11/21 11:41:30
VC6はゴミということで

198:デフォルトの名無しさん
08/11/21 11:44:17
まぁそりゃ暗黙に型変換されてるんだろう
警告なしにそういった型変換をするのはCの悪いところ
というか警告レベルを上げましょう

199:デフォルトの名無しさん
08/11/21 12:49:10
マルチスレッド対応で60ＦＰＳを維持する方法ってどうやるんですか？

200:デフォルトの名無しさん
08/11/21 12:59:59
ぇ？ｗ

垂直同期とか

201:デフォルトの名無しさん
08/11/21 13:57:29
>>196
49.7日待てば目覚めるはず

202:デフォルトの名無しさん
08/11/21 14:03:23
えいえんは、あるよ
49.7日ぐらい

203:デフォルトの名無しさん
08/11/21 19:43:02
>>197
Cの仕様なのに何言ってんだ。

204:デフォルトの名無しさん
08/11/21 19:58:03
Cはゴミということで

205:デフォルトの名無しさん
08/11/22 00:28:22
>196
まず警告レベルを上げろ。

206:デフォルトの名無しさん
08/11/22 10:52:51
>>205
警告レベル4にしたら
STLのライブラリのソースでwarnningが・・・
MS君・・・

207:デフォルトの名無しさん
08/11/22 22:06:38
STL で warning はよくあること。
まあ気にすんな。
鬱陶しければ #pragma warning(disable: XXXX) で消して
後で #pragma warning(default: XXXX) で復活させれば良い。

208:デフォルトの名無しさん
08/11/28 03:09:31
CreateThreadでクラスのメンバ関数って渡せますか？

209:デフォルトの名無しさん
08/11/28 03:21:05
なんとなく自己解決しました

210:デフォルトの名無しさん
08/11/28 16:46:25
test

211:デフォルトの名無しさん
08/12/01 19:47:00
>>201
INFINITE = 0xFFFFFFFF = (DWORD)-1

212:デフォルトの名無しさん
08/12/01 21:46:58
>>211
あーそうなんだー

213:デフォルトの名無しさん
08/12/02 00:26:53
P2Pや分散メモリに適した高速
ロックってどんなのがあるのですか？

214:デフォルトの名無しさん
08/12/02 00:43:43
とりあえず知ってる言葉を並べてみました。

215:デフォルトの名無しさん
08/12/02 07:57:29
>>213
高速なパッセージならやっぱ3大ギタリスト、とくにベックじゃね?
ルカサーも捨てがたいが
若いのは知らん

216:デフォルトの名無しさん
08/12/02 11:30:25
やっぱりクリティカルなセクションをアトミックに相互排他する場合
レスポンスタイムが長いメモリをダイレクトにアクセスするのは非効率だから
トランザクショナルメモリみたいな遅延する仕組みがマストニードじゃないですかね

217:デフォルトの名無しさん
08/12/02 13:11:00
日本語でおｋ

次ページ