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はこれでも読んでみれ
URLﾘﾝｸ(ja.wikipedia.org)
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
日本語でおｋ
218:デフォルトの名無しさん
08/12/02 13:27:51
やっぱり際どい領域を原子的に相互排他する場合
反応時間が長い記憶装置を直接読み書きするのは非効率だから
トランザクショナルメモリみたいな遅延する仕組みがどうしても必要じゃないですかね
トランザクショナルメモリだけはどうにもならんかった。
219:デフォルトの名無しさん
08/12/02 13:37:44
「処理単位記憶装置」かな？
220:デフォルトの名無しさん
08/12/02 14:44:45
都覧公国量産型六番書鳴記憶
221:デフォルトの名無しさん
08/12/02 20:55:12
ザクメモリってどうやってつくるの？
アルゴリズム全然解らん
222:デフォルトの名無しさん
08/12/02 21:45:47
弱そうなメモリだな
223:デフォルトの名無しさん
08/12/02 21:51:07
トラングフショナルメモリ
224:デフォルトの名無しさん
08/12/02 21:51:07
トランザクショナルメモリって
どんなアルゴリズムなのですかね？
何処探してもみつからない
225:デフォルトの名無しさん
08/12/02 22:02:31
ロックフリーあたりで調べればいいと思う
でもコストが大きい気がするのでリードライトロック程度で十分かと
226:デフォルトの名無しさん
08/12/02 22:14:10
リードライトロックの中にもフェアかフェアじゃないかで変わるけどね。
オブジェクト指向はハードウェアの都合までは吸収してくれんよなぁ。
マルチスレッドのデザパタ見ててそう思う。
227:デフォルトの名無しさん
08/12/02 22:44:09
排他制御書き込みって
pthread_rwlockで実現できますか？
228:デフォルトの名無しさん
08/12/03 00:04:59
素直にmutexつかっとけ
読み書き両方な
229:デフォルトの名無しさん
08/12/03 00:17:05
>228
排他制御書き込み実現しようとすると
pthread_mutexでは、try_lockを全mutex分
毎回ぶん回すってことでおｋなのかな？
この辺の定石ってよくわからん
230:デフォルトの名無しさん
08/12/03 03:01:55
mutexが複数あるの？
どういう排他制御をしたいのかわからん
231:デフォルトの名無しさん
08/12/06 15:29:07
スレッド2000個作って
画像データダウンロードするやつ作ったんだけど
スレッドが全部同時に動作しないんだ
どこがいけないんだ？
232:デフォルトの名無しさん
08/12/06 15:42:50
当てずっぽうだけどサーバが2000接続も同時に処理できないんじゃね
1個ずつ順番に処理して残りは待たされてるとか
233:デフォルトの名無しさん
08/12/06 15:53:38
そもそも2000スレッドが同時に動くはずがない。
234:デフォルトの名無しさん
08/12/06 15:58:58
1000コア*2(HT)ですね
もしそんなのがあったとしても現状Linuxしか動かせない
235:デフォルトの名無しさん
08/12/06 16:25:36
「全部同時に」ってのがどの程度の同時性を指してるんでしょうね
236:デフォルトの名無しさん
08/12/06 18:00:38
Sunのやつなら動くと思うよ
237:デフォルトの名無しさん
08/12/06 19:34:10
どの程度とかの精度の問題ではないんですよ
動けばいいだけのレベルなんですけど
for ループ内で約2000 個のスレッド作るんで、
タイミング的にはほぼ同時な気がしますが
OSにもよるかもしれませんが、
そうそう１０秒以上も差が出るとは思えないんで
精度は１０秒以内くらいの超おおざっぱでいいですけど
動かないんですよ
ちなみにCUI コマンドプロンプトで多数のスレッドから
printf されるとやはり多重に出力され
hogehogehogehoge が
hohohogegegehoge になったりするんでしょうか？
238:デフォルトの名無しさん
08/12/06 19:34:15
環境は？
win32じゃなさそうだが
239:デフォルトの名無しさん
08/12/06 19:45:36
Erlangなら60000スレッドぐらい起せるよ
240:デフォルトの名無しさん
08/12/06 19:54:33
>>237
標準出力はバッファリングされるので、混ざる場合はバッファサイズずつ混ざる。
>237のように1バイトずつ混ざることはない。
241:デフォルトの名無しさん
08/12/06 22:34:02
>>237
動かないってどう動かないんだよ。
242:デフォルトの名無しさん
08/12/06 22:45:56
>>238
機密事項なので書けません＞＜
243:デフォルトの名無しさん
08/12/06 23:39:13
おれも1万個ぐらい動かしてるけど別に問題ないな。
機密事項だから環境は書けないが。
244:デフォルトの名無しさん
08/12/06 23:53:58
＞スレッド2000個作って画像データダウンロードする
あほのすることだな
245:デフォルトの名無しさん
08/12/07 05:05:46
>>244
ネットワークモニタの使用率が25%超えたことないんで
限界までいどみたかったとです
246:デフォルトの名無しさん
08/12/07 05:36:11
>>245
自分で対向サーバを用意すれば簡単だよ。
247:デフォルトの名無しさん
08/12/07 06:44:22
スレッドって関係あるん？
248:デフォルトの名無しさん
08/12/07 07:44:39
>>247
deteike
249:デフォルトの名無しさん
08/12/07 10:16:03
2000個もスレッド作ってりゃオーバーヘッド大きすぎてそりゃ限界までいかんわな。
っていうかそもそもネットワークモニタって実効速度の％出してくれるんだっけ？？
250:デフォルトの名無しさん
08/12/07 11:04:38
>>249
タスクマネージャにあるよ
OSの限界ギリギリまで性能を出そうとしたのに
なんてOSだ・・・
251:デフォルトの名無しさん
08/12/07 11:48:23
馬鹿は巣にお帰りください。
252:デフォルトの名無しさん
08/12/07 15:04:34
だからなんでスレッドにすると帯域使用量が上がるんだっけ？
でっかいファイル一つを read するのと、スレッド2000個で read するので
差が出る理由はなに？
253:デフォルトの名無しさん
08/12/07 15:06:38
ネットワークの話じゃなかったのか。
254:デフォルトの名無しさん
08/12/07 15:19:33
ああ、そういうことね
1スレッドひとつにつき１つの画像をダウンロードするプログラムを組んだ
このスレッドを2000個同時に実行したけど
2000個同時（プログラム的には）には動作してくれなかった
ということ
255:デフォルトの名無しさん
08/12/07 15:47:41
だから、2000ポート空けて待つような対向サーバを自前で用意しろって。
256:デフォルトの名無しさん
08/12/07 16:10:56
>>252
思い込み
257:デフォルトの名無しさん
08/12/07 16:25:13
>>250
だからさあ、例えばギガビットイーサだったら100%って1Gbpsじゃないの？
実効速度250Mps出てても25%だぜ？
258:デフォルトの名無しさん
08/12/07 20:02:19
バス速度的に実際1Gbpsなんて無理
100Base-TXで考えなさい
259:デフォルトの名無しさん
08/12/07 20:07:35
FPGAのNICなら１Ｇっていったら１Ｇ出ますが？
260:デフォルトの名無しさん
08/12/07 20:08:02
うん
馬鹿は帰れ
261:デフォルトの名無しさん
08/12/07 20:11:23
>>254
そもそも、シングルコア、1スレッドあたりのタイムスライスを10msとすると、
1周するのに単純計算で10ms×2,000=20,000ms=20秒だ。実際には10msよりも
もっと長いのが普通(※1)だし、スレッド切り替えにもコストがかかる(※2)し、
マルチコアとしてもコア数分の1にしかならない上に、コア間の調停にも
やっぱりコストがかかる(※3)。
あと、ネットワークの実効速度についても、デカいパケットが順番に流れる
なら、かなり帯域上限に近付けることができるが、細かいパケットが非同期に
衝突しまくりながら流れるようだと、いいとこ1/3くらいしか出ない。
ぶっちゃけ、アプローチが間違ってるとしか思えん。
※1:ぐぐってみたところ、Windowsについてはこんなんが引っかかった。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
もっと良い資料やUNIXについての言及があれば教えてくれ。
※2:レジスタ等のコンテキスト情報を全部保存してパイプラインを捨てて
他スレッドのコンテキストを読み込む。キャッシュから溢れてたら最悪
メインメモリまで取りに行くハメになるぞ。
※3:各コアが互いに読み書きできるレイヤまでデータが届く必要があるため。
262:デフォルトの名無しさん
08/12/07 20:37:21
たしか一般に、CPUサイクルで見て、
スレッド作成が数万～10万サイクル（ひょっとすると数十万～だったかも）、
コンテキストスイッチが数千～1万サイクル
とか見た気がする。
263:デフォルトの名無しさん
08/12/07 20:38:37
おっと、スレッドに関わるオーバーヘッドの話ね。
264:デフォルトの名無しさん
08/12/08 01:15:52
>>262
＞コンテキストスイッチが数千～1万サイクル
今時LinuxでもO（1）スケジューラなわけだが。
265:デフォルトの名無しさん
08/12/08 01:22:44
そりゃ的外れなレスなこって
266:デフォルトの名無しさん
08/12/08 01:48:56
ﾜﾛﾀ
267:デフォルトの名無しさん
08/12/08 09:39:27
WindowsとかLinuxとか・・・
そんな貧乏臭いOSの話ばっかでワロタ
268:デフォルトの名無しさん
08/12/08 10:27:54
そうですか
269:デフォルトの名無しさん
08/12/08 13:48:37
アセンブラ級はついていけｎ
270:デフォルトの名無しさん
08/12/08 18:58:28
何十万ものスレッドをサポートするようなシステムもあるんだよね？
どういう構造になってんだろ
根本的に考え方からちがうのかな？
271:デフォルトの名無しさん
08/12/08 19:01:51
>>270
カーネルスレッドは使わない（ユーザスレッドでやる）、か、そういうスレッドを
サポートしたカーネルでないと無理。普通のUnixの普通のカーネル（含むLinux）
とかだと無理。
272:デフォルトの名無しさん
08/12/08 21:55:16
OSはWindowsXPなんですよ
で、ソースですが
for( int i=0; i<2000; i++ )
{
_beginthred( DoIt, 0, NULL );
}
void DoIt( void * )
{
DownloadURL( URL, filename );
_endthread();
}
ってな感じですけど
ほとんど同時時間にスレッドを起動させてるのですが、
タイムスライスが各スレッドに割り当てられないのでしょうかね？
それともやっぱり >>232 さんの言っているように
サーバー側が延滞処理をほどこしているんでしょうかね？
問い合わせたくてもあまり進んで聞けるようなことではないので
273:デフォルトの名無しさん
08/12/08 22:05:16
>272
スタック用の仮想メモリが足りなくなってない？
あるいは、その呼んでいるDownloadURLが
STAみたいな実装とかｗ
>261
IOが支配的なスレッドで、タイムスライスの意味なんか
ほとんどないとおもうけど。
274:デフォルトの名無しさん
08/12/08 22:48:50
同一サーバにHTTPコネクションを2000張ろうとしていたオチと予想
275:デフォルトの名無しさん
08/12/08 23:28:21
Irvineとかで試してみればどうかな
276:デフォルトの名無しさん
08/12/08 23:41:31
>>274
攻撃とみなされても仕方ありませんな
277:デフォルトの名無しさん
08/12/09 00:06:27
>>273
仮想メモリなのに足りなくなるとは、これいかに。
278:デフォルトの名無しさん
08/12/09 00:15:39
2000個のスレッドでスタックだけで仮想メモリ使い切るだろWin32なら。
279:デフォルトの名無しさん
08/12/09 00:20:56
いくらIOバウンドだって普通2000はやりすぎ。
普通はせいぜい100までだろう、CPU数にもよるがそれでも多いくらいだろう。
だいたい2000個の各ファイルのサイズはどのくらいで、
単体での転送速度はどのくらいなんだ。
ってダウンロードが2個までしか同時に動いてなかったりしてなｗ
あとサーバ側も普通は当然そんなに同時処理できない
キューに入って順番に処理されるだけ。
280:デフォルトの名無しさん
08/12/09 01:06:30
>>278
> 2000個のスレッドでスタックだけで仮想メモリ使い切るだろWin32なら。
相変わらず意味不明。
281:デフォルトの名無しさん
08/12/09 01:07:09
俺がワーカスレッドをプールする場合は、
特に深く考えずに単にコア数の倍だけ用意しとく。
IOブロックで動けるようになった他のスレッドもIOでブロックされるだけだしね。
282:デフォルトの名無しさん
08/12/09 01:23:17
>277,280
正確には仮想メモリ空間。
Win32では、ふつー、プロセス毎に、ユーザ空間として
使用可能なのは、下位から7fffffffあたりまでで、2GB。
だいたい、ポインタが32bitであることの限界とみていい。
で、Win32のスレッドは、１つあたり、規定では1MBの
スタックを仮想メモリ空間に確保する。他にもDLLとかの
コード領域も同じ2GBの空間を使うわけで。
283:デフォルトの名無しさん
08/12/09 01:35:04
>>282
仮想メモリというのはプロセス毎にあってだな・・・
284:デフォルトの名無しさん
08/12/09 01:47:50
>>283
>237嫁
285:デフォルトの名無しさん
08/12/09 01:56:53
>>283のおバカさを示すなら>>191の方が適切だろ。
286:デフォルトの名無しさん
08/12/09 09:08:47
>>281
だったらコア数の2倍はちょっと少なくない？
まあIOってもネットワークなどの場合で、
もちろん少ない投入数で帯域使いきれるような場合や
同一サーバにつなぐような場合は別だが。
287:デフォルトの名無しさん
08/12/09 10:26:51
Win32(笑)
288:デフォルトの名無しさん
08/12/09 10:28:16
ネイティブなプロセスやスレッドで並列性増やす方法は全然スケールしないから
軽量プロセス／スレッドが流行るんだろ
Erlangのような言語は言語のレベルでそういうものをサポートしている
目的がI/O多重化なら昔ながらのselect系のシステムコールが使える
WindowsならIOCP
Javaは1.4以降でnioという形でそれをサポートしてるし
Cならlighttpdで使われているlibeventのようなものがある
それはそうと、Windows XPあたりだと、デフォではTCPの同時接続数が10だかに
制限されているはずだが
289:デフォルトの名無しさん
08/12/09 12:08:39
>>288
ソースは？
290:デフォルトの名無しさん
08/12/09 12:11:40
>>289
「どれ」についてのソースなのか分からんが、
最後のものについてなら、そのまんま
Windows XP 同時接続数
でぐぐればいくらでも情報が手に入るだろ
291:デフォルトの名無しさん
08/12/09 12:18:08
UDPは制限あるの？
292:デフォルトの名無しさん
08/12/09 12:19:40
知らん
UDPにはconnectionという概念がないから、多分無いんじゃないかとは思うが
自分で調べたらどうだ
293:デフォルトの名無しさん
08/12/09 12:25:13
いやです
ありがとうございました
294:デフォルトの名無しさん
08/12/09 12:40:30
ググってみたが、XPのSP2から1秒間につき10コネクションという
制限がついたらしい。
時間をあければ万単位までいけるみたいだが。
295:デフォルトの名無しさん
08/12/09 12:40:39
Windows XP Professional の場合、ネットワーク経由で同時に接続することができるコンピュータの最大数は 10 です。
とありますが、
メッセンジャーに繋げてますが
この状態だと最大数は9になるのでしょうか？
296:デフォルトの名無しさん
08/12/09 13:11:01
制限解除するパッチもあるよ。公式じゃないけど。
297:デフォルトの名無しさん
08/12/09 13:11:23
もう少し詳しく調べてみた。
同時最大接続数が10に制限されるのは、listenする側の制限。
ようするに自分がサーバになる場合。
外向きの接続に関する制限は、half-open connectionが
1秒間に10個までに制限されている。(SP2から)
half-open connectionは相手がacceptしてない接続のこと。
外向きの接続数に関しては、能力的な限界以外に制限は無さそう。
ただし1スレッドにつき64ソケットの上限有り。(回避は可能)
298:デフォルトの名無しさん
08/12/09 13:13:51
>>297
え？内向きの制限はもともとサーバー系でない奴にはついていて、
XP SP2以降のは、外向きの制限だろ？
299:298
08/12/09 13:15:20
要は、listenじゃなくて、外に貼りに行くコネクション数に制限がついたってことな
300:デフォルトの名無しさん
08/12/09 14:35:58
>>298-299
そういう制限は見当たらなかった。
日本語の非プログラマ系のブログでそう書いてるところはあるが、勘違いだろう。
実際にセッションモニタ見てると、10なんて余裕で超えてるし。
301:デフォルトの名無しさん
08/12/09 14:47:37
>>300
は？
Event ID 4226でぐぐれよ
秒間の「外向きの」同時接続試行回数に関する制限で、
非公式のtcpip.sysに対するパッチも出ているから
302:デフォルトの名無しさん
08/12/09 15:00:15
P2Pとかやると直ぐでるからわかる
303:デフォルトの名無しさん
08/12/09 15:12:52
ああ、論点のずれが分かった
10個以上のTCP/IPのコネクションが維持できないって制限じゃないだろ
秒間に10個以上SYNパケット（TCPの最初のハンドシェイクで使う）を
投げないようにしているだけのはずだ
要するにスレッド沢山つくって並列でダウンロードさせようとしたところで
10個目以降ではconnect()呼んだ時点で制限にひっかかり、少なくとも他の
ハンドシェイクが完了するまでは待たされるってこった
304:デフォルトの名無しさん
08/12/09 15:36:05
ちゃんと297でhalf-open connectionと書いたんだが。
それを否定されたら、同時セッション数としか読み取れないよ。
305:デフォルトの名無しさん
08/12/09 15:45:44
そうだな、よく読んでなかった
すまん
306:デフォルトの名無しさん
08/12/09 17:47:13
クライアントでどこまでスケールさせる気だ。
307:デフォルトの名無しさん
08/12/09 20:04:18
googleのクローラでね？ｗ
308:デフォルトの名無しさん
08/12/10 17:25:35
シングルスレッドでダウンロードするとうまくいくのですが
マルチスレッドでダウンロードするとエラーが返ってきて
GetLastError() で戻り値を調べても 0 で何が原因か分からないのですが
どなたか分かりませんか？
WinXP です
309:308
08/12/10 17:29:32
マルチスレッドといっても、デバックの為、スレッドはひとつなので
競合などはおきないように設計しているのですけど、うまくいかないのです
310:デフォルトの名無しさん
08/12/10 17:39:11
さすがにそれだけで答えろって言われても、俺には無理だな。
GetLastErrorを呼ぶスレッドは合ってるの？
311:デフォルトの名無しさん
08/12/10 17:42:36
ダウンロードはどのAPIを使っているの？
312:デフォルトの名無しさん
08/12/10 19:15:01
>>311
ググってもでないのよねﾌﾌﾌﾌﾌﾌﾌﾌﾌ
313:308
08/12/10 19:19:36
>>311
機密事項なので答えられません＞＜
314:デフォルトの名無しさん
08/12/10 20:40:26
>>311
WinInet
InternetOpen
以外のAPIだけとは言っておく
315:デフォルトの名無しさん
08/12/10 20:42:31
>>311
とあるライブラリなんです
何かはいえませんが
316:デフォルトの名無しさん
08/12/10 20:55:51
俺は原因わかったよ
ここには書けないけど
317:デフォルトの名無しさん
08/12/10 21:36:55
内々に連絡しておいた。
318:デフォルトの名無しさん
08/12/11 03:36:59
Debug版を納品とかﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
319:デフォルトの名無しさん
08/12/11 09:31:46
ソースも示さずデバッグ依頼とな。
320:デフォルトの名無しさん
08/12/11 09:37:51
ソース。
ｽﾚﾘﾝｸ(mnewsplus板)
残念ながらもう消えてしまったようだが。
321:デフォルトの名無しさん
08/12/11 12:06:37
>>318
お主もなかなかのﾌﾌﾌﾌﾌﾌ
でもユーザー名ばれるのよねﾌﾌﾌﾌﾌﾌﾌｯﾌﾌﾌﾌﾌﾌｯﾌ
322:デフォルトの名無しさん
08/12/11 12:29:11
夜中にひとりでデバッグしてる時に
ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
とか
feeefeee feeefeee feeefeee feeefeee
とか見ると鳥肌が立ちそうになる・・・
323:デフォルトの名無しさん
08/12/11 14:11:44
POSIXスレッドでmutexロックでのデッドロックの回避法教えてください
324:デフォルトの名無しさん
08/12/11 14:27:28
馬鹿どもにマルチスレッドを走らせるな
325:デフォルトの名無しさん
08/12/11 14:36:53
>>323
2個以上のmutexを同時にロックしないというルールを徹底させるのが一番簡単かと
326:デフォルトの名無しさん
08/12/11 15:32:14
走る～♪
走る～♪
スレッドーたーちー♪
327:デフォルトの名無しさん
08/12/11 15:32:57
馬鹿ですいません＞＜
328:デフォルトの名無しさん
08/12/11 15:58:59
_beginthread( multi, 0, data );
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
>はわわわわ～
329:デフォルトの名無しさん
08/12/11 18:46:03
APIの問題ではなかったようだ
設計の問題だったようだ
これは普通気づかない
330:デフォルトの名無しさん
08/12/11 20:45:05
Critical!
Criticalなのぉ～
Criticalな処理をしていなかったのぉ～
んぼおおおおおおおおおおおおおおおお
331:デフォルトの名無しさん
08/12/12 04:49:09
馬鹿はマルチスレッドやっちゃだめだよ。
死んだじっちゃんの口癖だった。
馬鹿って言うのは思考力が著しく劣る人なんだけど、
具体的に例をあげれば、自分で調べて答えを見つけられない人の事なんだ。
332:デフォルトの名無しさん
08/12/12 07:20:42
だ～か～らぁ～
ぐぐってもgooで聞いてもダメなのぉぉぉぉ～～～～
333:デフォルトの名無しさん
08/12/12 11:05:47
デッドロック 予防 とか、デッドロック 回避 とかで検索して、端から見ていってみ。
334:デフォルトの名無しさん
08/12/13 13:36:29
１スレッド
２スレッド
３スレッド
４スレッド
５スレッド
全部ためしたののですが１スレッドが一番早かったです
どうしてでしょうか？
335:デフォルトの名無しさん
08/12/13 14:23:51
よくあることです。
336:デフォルトの名無しさん
08/12/13 14:40:12
何を試したんだよ
337:デフォルトの名無しさん
08/12/13 17:25:44
キアイ
338:デフォルトの名無しさん
08/12/13 19:48:33
あるスレッドで処理した結果をメインスレッドに渡したいのだがどうすればいい？
_beginthreadexの第3引数に結果用のポインタを渡せばいいのか
339:デフォルトの名無しさん
08/12/13 20:43:24
典型的にはソウデスナ
処理してほしい内容と
処理結果の格納場所を
与えるのがよろしいかと思いますダ
340:デフォルトの名無しさん
08/12/14 01:39:30
>>338
CPUにお祈りする
341:デフォルトの名無しさん
08/12/14 02:58:11
>>334
マルチスレッド化して速くなるかどうかは状況による。
その状況がわからなきゃ、何とも言えない。
342:デフォルトの名無しさん
08/12/16 07:49:17
>>338
グローバル変数でいいよ
メモリ空間を共有してるのがスレッドのメリットなんだし
343:デフォルトの名無しさん
08/12/16 09:18:38
…
344:デフォルトの名無しさん
08/12/16 11:09:40
volatile最強
345:デフォルトの名無しさん
08/12/16 11:13:32
>>388
俺はそういう場合スレッドセーフなスマートポインタ使うな
スレッドにデータを渡す前に参照カウント増やしといて
スレッド側では使い終わったら解放
メインスレッドは結果が必要なくなればスレッドが終了していなくてもデータを解放できる
346:デフォルトの名無しさん
08/12/16 11:22:01
クラスにしてthis渡してるな
class tiny_thread abstract {
protected:
HANDLE m_hthread;
unsigned m_id;
： いろいろメンバー
private:
static unsigned WINAPI thread_start(void *o) {
tiny_thread *tt = (tiny_thread *) o;
return tt->run();
}
public:
bool start() {
m_hthread = (HANDLE) _beginthreadex(NULL, 0, thread_start, this, 0, &m_id);
return m_hthread != 0;
}
virtual int run() = 0;
};
347:デフォルトの名無しさん
08/12/16 15:41:15
>>388は素人童貞
348:デフォルトの名無しさん
08/12/16 15:56:58
>>388 に期待
349:デフォルトの名無しさん
08/12/17 01:34:39
・メインスレッドが必ずサブスレッドより長生きするようにする。
メインがサブをjoinなり必要に応じて中断するなりする。
・結果格納場所のポインタやコールバック関数のアドレスをサブに渡す。
メインがUIスレッドの場合、サブからPostThreadMessageした方が楽かも知れない
・通信用メモリの解放責任をメイン側と決めておく
>>345みたいなサブスレッドだけ生き続ける設計は個人的に(GCの無い言語では)嫌だ
これらが難しいと思うなら>>342だね。カッコ悪いけど確実かな
350:デフォルトの名無しさん
08/12/17 01:53:27
PostThreadMessageは取りこぼしが発生するので使っちゃいけません。
PostMessageを代わりに使おう。
351:デフォルトの名無しさん
08/12/20 00:19:42
ところで、ファイバーってどうなん。
アイドル状態のスレッドでパカパカやって動かすとか
スケジュール処理なワーカスレッド代わりとかしか思い浮かばん。
漏れは、スレッドの処理は概ね、待ち処理とか先行処理なので、
あまり使い方が思い浮かばない。
352:デフォルトの名無しさん
08/12/20 01:51:56
>>351
ファイバーは移植のためにあるようなもので
新規プロジェクトで使う価値は無に等しい。
353:デフォルトの名無しさん
08/12/20 02:10:30
>>352
短絡杉
プリエンプティブであることは必ずしも望ましいことじゃない。
ゲームではファイバーが好まれる。
Larrabeeでもシェーダはファイバーで実装されるそうだ。
マルチコアでハイパフォーマンスだすためにファイーバーは重要。
354:デフォルトの名無しさん
08/12/20 02:31:59
自分でコンテキストスイッチとかめんどくせぇぇぇ
355:デフォルトの名無しさん
08/12/20 03:01:53
ちまちま排他処理すんのめんどくせぇぇぇ
356:デフォルトの名無しさん
08/12/20 12:21:50
>>352、353
マルチスレッドで複数の関数叩くのと、ファイバーを複数キックするのの違いってやっぱ、
同期処理が不必要(他のスレッドでキック中のファイバーは自動的に同期される？)だとか
スタックの制限(ファイバーキックされた段階でスタック指定できる)ですか？
いえ、無論色んな意味合いで違うことは判るけど。
357:デフォルトの名無しさん
08/12/20 16:20:24
int result = write( buf, size );
if( result == -1 && errno == EAGAIN ) SwitchNextCoroutine();
I/Oイベントドリブンなスケジューラをみたことある。↑みたいなの。
あとは同期が要らないってのが素晴らしい。
358:デフォルトの名無しさん
08/12/20 20:34:51
VisualStudio 2010にはC#のyieldを使ったファイバーもどきライブラリが付いてくるらしいね
URLﾘﾝｸ(channel9.msdn.com)
359:デフォルトの名無しさん
08/12/20 23:50:27
それは歪でいまいちだね～
まずコルーチンがあって
それにスケジューラを足してファイバー
イテレータ風に味付けしてジェネレータ(C#のyieldのことね)
という階層があるべき姿だと思うな。
360:デフォルトの名無しさん
09/01/10 00:18:47
64CPU環境でスレッドを256本生成したときに
struct data[2000];
なんてあって、dataの個々の要素を排他的にアクセスしたい場合
pthread_mutex以外に使えそうな手段ってありますか？
CASってどうやって使うのかよくわからんし助けて
361:デフォルトの名無しさん
09/01/10 00:48:43
pthread_mutexでマズい理由は？
362:デフォルトの名無しさん
09/01/10 00:58:20
>>361
2000個もpthread_mutex_tって用意して使えるのですかね？
363:デフォルトの名無しさん
09/01/10 01:08:25
発想が変？
364:デフォルトの名無しさん
09/01/10 01:47:06
mutexを2000個作って問題ないと思うよ。
自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
でパフォーマンスの問題が出たらそのときに対処を考える。
reader-writerロックが使えれば使う。
365:デフォルトの名無しさん
09/01/10 01:47:49
訂正。
> 自分だったら、struct data[200] 全体に対して1個のmutexにして、それ
struct data[2000] ね。
366:デフォルトの名無しさん
09/01/10 18:28:23
>>362
pthread_mutex_t はただのデータだから、何個作っても
そのプロセスのメモリ以外の資源は使わない
367:デフォルトの名無しさん
09/01/11 00:54:05
連結リストをCAS使って実装するときのお手本ってありますか？
368:デフォルトの名無しさん
09/01/11 01:04:19
>>367
URLﾘﾝｸ(www.cs.rochester.edu)
369:デフォルトの名無しさん
09/01/11 01:14:01
双方向は無いのか........................
370:デフォルトの名無しさん
09/01/11 01:50:26
双方向でできると思ってんのかっ
371:デフォルトの名無しさん
09/01/19 00:40:02
rw_lockAPIが存在する環境で
同じrw_lock変数を以下のような構造で使うのって
問題ないでしょうか。
func()
{
rw_lock(read)
if 条件{
rw_lock(write)
rw_unlock(write)
}
rw_unlock(read)
}
372:デフォルトの名無しさん
09/01/19 02:34:03
オレオレOSのオレオレrw_lock APIなら大丈夫だけど？
373:デフォルトの名無しさん
09/01/19 13:24:35
実装次第だが、普通に考えるとデッドロックするな
374:デフォルトの名無しさん
09/01/19 21:32:54
r_lock 確保してるんだから if の中の w_lock が取れないだろjk
375:デフォルトの名無しさん
09/01/20 06:28:27
なぜrでロックしないといけないのかわからんけど、条件に関わるのか？
376:デフォルトの名無しさん
09/01/20 11:21:30
>>375
このパターン自体は典型的なケースだろ
APIによっては、ReaderとWriterの他に「Writerに変更可能なReader」が用意されていることもある
377:デフォルトの名無しさん
09/01/27 16:00:09
WindowsでCreateThread中Cランタイムに含まれる関数を使うとリークを起こすとありますが、
普段からCreateThreadは使わずbeginthreadを使ったほうがいいんですか？
完全にCランタイム使わずってのも面倒だし、内部で使ってる関数があるかもしれない
そういうことまで考えてあえてCreateThreadを使うメリットはあるのでしょうか？
378:デフォルトの名無しさん
09/01/27 16:06:34
軽い
379:デフォルトの名無しさん
09/01/27 16:14:38
ない
380:デフォルトの名無しさん
09/01/27 17:56:15
_beginthreadexでおｋ
381:デフォルトの名無しさん
09/01/28 14:15:26
ないな
382:デフォルトの名無しさん
09/02/01 13:59:30
pthreadでmutexで
再起ロックする場合と
依存関係をハッキリさせてスレッドIDとFAST_MUTEXで判別
どっちが高速ですか？
383:デフォルトの名無しさん
09/02/01 15:33:29
後者。
以前計測したことがある。
ただし、依存関係の洗い出し作業がとても大変だった。
デッドロックに直結するから、とても気をつけないといけない。
要求性能がシビアだったから後者で仕事のためにやったけど、趣味ならば前者をお薦めする。
排他制御がボトルネックになるようなら、前者で実装すればいい。
俺の場合は、本当に特殊で制限が厳しかったから前者でやっただけ。
384:デフォルトの名無しさん
09/02/01 15:35:13
×排他制御がボトルネックになるようなら、前者で実装すればいい。
○排他制御がボトルネックになってから、後者で実装すればいい。
385:デフォルトの名無しさん
09/02/01 15:38:02
FAST_MUTEXって何？
386:383
09/02/01 16:18:24
色々ぐだぐだだな。
お家で寝たいよ。
387:デフォルトの名無しさん
09/02/01 23:25:11
struct hoge{
int var
pthread_mutex_t m;
struct hoge * next;
};
こんな構造体あって
while(h){
pthread_mutex_lock(h->m);
h->var++;
pthread_mutex_unlock(h->m);
h = h->next;
}
こんな風にリンクリストを舐める前後を排他して
舐めていくという処理は正しいでしょうか？
388:デフォルトの名無しさん
09/02/01 23:54:31
加算をアトミックにしたいなら正しいんじゃない。
389:デフォルトの名無しさん
09/02/02 00:06:27
>>388
では、これもレースコンディション無く
検索可能ですかね？
struct hoge{
int var;
int id;
pthread_mutex_t m;
struct hoge * next;
};
void search(id)
{
while(h){
pthread_mutex_lock(h->m);
if( h->id == id){
h->var++;
pthread_mutex_unlock(h->m);
return;
}
pthread_mutex_unlock(h->m);
h = h->next;
}
}
390:デフォルトの名無しさん
09/02/09 14:04:10
shared_ptrで管理するオブジェクトAをスレッドXに渡し、スレッドXからdllを呼んで、dll内でオブジェクトAのメモリを確保する、
ということをしたいのですが、以下のコードでjoin終了時、shared_ptr<A>の解放処理のところで例外が発生します。
どういった理由が考えられるでしょうか？
マルチスレッドでもdllを使わなければ問題なし、dllを使ってもマルチスレッドにしなければ問題なしでした。
struct A {}; // スレッドXにshared_ptrで渡されるデータ
typedef void (__cdecl* DllFunc)(std::tr1::shared_ptr<A>& a); // スレッドから呼ばれるDLL
struct X { // boost::threadに渡すスレッドオブジェクト
std::tr1::shared_ptr<A> a_;
X(std::tr1::shared_ptr<A> a) : a_(a) {} // DLLに渡すデータ
void operator()(void) { // スレッド実行時に呼ばれる関数
HMODULE handle = LoadLibrary(L"dll_func.dll");
DllFunc dll_func = (DllFunc)GetProcAddress(handle, "dll_func");
dll_func(a_);
FreeLibrary(handle);
c.notify_one();
}
};
int main(int argc, char** argv) {
std::tr1::shared_ptr<A> a(new A);
std::tr1::shared_ptr<X> x(new X(a));
boost::thread th(*x);
th.join(); // ここで例外発生
}
<dll_func.cpp>
BOOL WINAPI DllMain (HINSTANCE hinstDll, DWORD fdwReason, LPVOID lpvReserved) { return TRUE; }
extern "C" __declspec(dllexport) void __cdecl dll_func(shared_ptr<A>& a) { a.reset(new A); // これがなければ大丈夫 }
391:デフォルトの名無しさん
09/02/09 15:33:18
よりによってここに書くか。すれ違いだWin32スレ行け。
DLLの勉強一からやりなおせ。
最初から全コードのせときゃもっと早く回答ついたんだろうが、ウザイからオシエネ。
392:デフォルトの名無しさん
09/02/09 16:58:44
DLL内でnewしたのをEXE内で解放したらエラー出るんじゃない？
そもそもshared_ptrだって内部で参照カウント用にnewしてるからDLLじゃ使えない気がするなー。
393:392
09/02/09 17:02:58
スレッドは全然関係ないね。うん。
394:デフォルトの名無しさん
09/02/10 05:13:43
>>390
たぶんこれだけで死ねる。
std::tr1::shared_ptr<A> a(new A);
X(a)();
395:デフォルトの名無しさん
09/02/10 21:54:55
DLLか・・・COMについて調べたほうがいいんじゃないですかね
いろいろヒントあるよ
396:デフォルトの名無しさん
09/02/14 15:33:17
shared_ptr使ってるくせにdeleter知らないとか
397:デフォルトの名無しさん
09/02/19 23:31:28
>>288
Windows Xp home SP3 で自作のTCPサーバ運用してるけど、インバウンド接続の
同時接続数の制限が10ってことはないよ。
今モニタ見ても20人くらい繋がってる。
p2pがすごい数でつながってるだろうし
この件についてはいろいろなひとがよく確かめずにいろいろ書いてる。
自分でちょっとやってみればすぐわかる。
398:デフォルトの名無しさん
09/02/19 23:33:34
>>397
実装はともかくライセンスで制限されてるはず
399:デフォルトの名無しさん
09/02/19 23:37:37
そうなんだよね。 使わないでくれという約束で みんな破って使ってるわけだ。
400:デフォルトの名無しさん
09/02/19 23:46:20
SQLだったかで試してたときにイベントログに制限されたメッセージが
出たことある。あとShare動かしてる時とか頻繁に出る気がする。
単純にセッションの制限では無かった筈。
401:デフォルトの名無しさん
09/02/20 00:12:50
MS製のサーバは独自に制限した実装 IISじゃなくてPWSだっけ
WMEとかはレジストリいじって50人くらいつないだりしてたな。
402:デフォルトの名無しさん
09/02/20 02:13:42
それとは別に、セキュリティ的な話で、
SYN_SENTなソケットをシステム全体で
10くらいしか持てないって制限もあったはず。
403:デフォルトの名無しさん
09/02/22 19:23:55
初心者な質問ですが、
Thread A Thread B
for(;;) for(;;)
printf("AAA\n"); printf("BBB\n");
という処理を行うと、AAA行とBBB行が入り乱れて表示されるんですが、
AABABB\n\n などと表示されることはありえないんでしょうか。
環境はWindows XPで、VC++2008EEでプログラムを書いてます。
404:デフォルトの名無しさん
09/02/22 19:36:03
>>403
ここらへんに何か書いてあるんじゃねーの？
URLﾘﾝｸ(msdn.microsoft.com)
405:デフォルトの名無しさん
09/02/23 04:04:56
>>403
バッファリング
406:デフォルトの名無しさん
09/02/23 21:19:24
スレッドに別のスレッドから信号を送って途中で処理をキャンセルしたいのですが、
現状、以下のようにしています。
void run() { // スレッド実行部
for () { // 長いループ
...処理...
if (check()) return; // 処理をキャンセル
}
}
check()でキャンセルのフラグをチェックし、このフラグを別のスレッドから書き換えるという方法です。
でもこの方法だとループ内の処理が重くなったときにキャンセル操作に対する反応も遅くなってしまうため
どうしたものかと悩んでます。
スレッド内でタイマーのようなものを発行して、定期的にcancel()のチェックをするといった方法はできないでしょうか？
環境はVC9です。
407:デフォルトの名無しさん
09/02/23 22:47:56
>>406
別スレッドから強制停止するとリソースリークの元だよ。
if (check()) return; // 処理をキャンセル
を重い処理の途中に幾つか入れる方がまし。
408:406
09/02/23 23:51:22
>>407
> を重い処理の途中に幾つか入れる方がまし。
どうも。やっぱりこういう単純な方法しかないですか。
重い処理を別スレッドで行わせながら
キャンセル操作の反応がよい安全な方法ってのはないんでしょうか。
cancel()を挿入しまくるというのもなんだかスマートじゃないなぁ･･･。
409:デフォルトの名無しさん
09/02/24 00:50:35
非同期に飛ばされるぐらいならコードが汚くなる方が良い
と思うのは俺だけじゃないよな？
410:デフォルトの名無しさん
09/02/24 01:12:42
その重い処理ってのがなんなのか
スマートとか言うならその重い処理をスマートに分割すりゃいいじゃない
どうしてもチェックしまくりたくないっていうなら処理を持ってるクラスのインスタンスを急にnullにしてやって
例外捕らえて終了してしまえ、最悪だけど
411:デフォルトの名無しさん
09/02/24 01:40:59
別プロセスにして殺すってのは？
結局そういうのって要求されるキャンセル応答時間次第。
人間相手ならmsecオーダでおｋでしょ。
きっとループ1回につき1msecもかからないのでは？
412:デフォルトの名無しさん
09/02/24 01:51:03
ワーカースレッド2つ以上用意にして
対処すればよくね？
複数個のスレッドでビジー状態になるなら
その処理内容そのものを分割しタスク化した方がいい
413:デフォルトの名無しさん
09/02/24 02:50:07
違う質問スレで質問した後でこちらを見つけたので一応こちらでも・・・
CreateThread関数で第三引数をクラスのメンバ関数にしたい場合は
どういう記述をすればいいのか教えてください
よろしくお願いします
414:468
09/02/24 02:56:15
>>410
>その重い処理ってのがなんなのか
例えば大きなサイズの行列計算や、待ち行列を使った探索問題なんかを想定しています。
問題を分割することはある程度はできるんですが、それはそれで頑張るとして、
それ以外のアプローチははないかなと。
>>411
> 別プロセスにして殺すってのは？
すみません。よくわかりません。
別プロセスならば殺しても元のプロセスに影響がでないという意味でしょうか。
>>410の後半で言ってることに近い
>>412
> ワーカースレッド2つ以上用意にして 対処すればよくね？
同じスレッドオブジェクトをAとBの２つ用意して、
Aが動いてるときにキャンセルしたときはキャンセルしたふりをして
（Aの計算は次のcancel()チェックまで続いてる）、
新規の呼び出しがあったときはBを動かすというイメージですか？これはいけるかも…。
415:468
09/02/24 02:58:01
一部修正
>>410の後半で言ってることに近い
↓
>>410の後半で言ってることに近いですか？
416:デフォルトの名無しさん
09/02/24 07:10:44
>>413
コールバック関数にはstaticなメンバ関数(クラスメソッド)しか使えない。
コールバック関数を使うAPIは大抵ポインタ型の引数を渡せるから、
クラスを使いたいときはそこにthisポインタを渡して使う。
417:デフォルトの名無しさん
09/02/24 08:52:04
>>413
できない
普通の関数作ってその中で呼び出す
418:デフォルトの名無しさん
09/02/24 16:53:09
>>416‐417
ありがとうございます
とりあえず、>>417の方法でやってみます
419:デフォルトの名無しさん
09/02/24 20:52:23
>>414
別プロセスにすると、ターミネートしたときのリソースの開放をＯＳがやってくれる
ってことではあるまいか。
それはともかく、その長い処理がうまく分割できず、どうしても時間がかかる場合は
汎的には、キャンセルボタンの入力を取得する側（フラグを立てる側ね）で、キャンセルが
押されたからしばらく待てっていうサインをユーザーに与える方が重要な希ガス。
420:デフォルトの名無しさん
09/02/24 21:45:33
別プロセスのほうがクリーンアップの点では簡単＆安心だなあ
ただ、多くの情報を受け渡したり、途中で通信が必要だったりすると
しんどいけどな
421:デフォルトの名無しさん
09/02/24 23:05:03
しんどいと言うか、性能の問題がでるかも
422:406
09/02/25 00:45:53
>>419-
なるほど。別プロセスにすることも検討できそうです。
なんとなく雰囲気は分かりました。どうもありがとう。
423:デフォルトの名無しさん
09/02/25 18:38:04
処理毎に別プロセスって、昔の業務アプリみたいだな。っていうか、
今でもVBあたりでそんな開発やってそう。
1画面＝1exeファイルで、画面間はsystem()でプロセス呼び出し。
画面フォーム上で入力したデータ等は、ファイルに書き出して渡す。
大抵、exeファイルの名前は全部数字と意味不明なアルファベットで、
メモリ食いまくりで、やたらに遅い。(w
424:デフォルトの名無しさん
09/02/25 19:28:47
大規模なアプリはマルチプロセスの方が開発しやすいね
Windowsの場合は性能的にマルチタスクに向かないけど
425:デフォルトの名無しさん
09/02/25 21:04:19
>>423
unixだとマルチプロセスは多いけどな。
VB6のアプリだとそういう作りになるのは仕方ない。
モジュール分割の手段がCOMしかない。
２０画面もあるとロードモジュールが１０M超える。
IDEに読み込んだりコンパイルするのにも一苦労。
プロセス間でDBのセッションを引き継げたらマルチプロセスでも軽くなるはずなのだけど、
それも出来ないからDBの接続でどうしても画面遷移が重くなってしまう。
426:425
09/02/26 01:19:09
>>424
マルチスレッドは、スレッド間のメモリ保護機構がないので、他スレッド
による破壊のリスクと引き換えに、高速なデータ共有が可能と思うが？
Windowsがマルチタスクに向かないとか、何を根拠に？
>>425
昔はメインメモリが少なく高価だったという事情もあるし、「unixだと」
という括りはどうかな？
20画面なんて、そんなに大きな規模なプログラムじゃないよね？その程度
の規模で単純にVBのソースだけなら、10MBを超えるようなことはないの
では？
確かにVB6当時のハード環境（Pentium 300MHz～1GHz, メモリ64MB程度?）
でのビルドは遅かったかもしれないが、VBはVCよりは速かった様に記憶
しているけど？
それと、プロセス間でDBのセッションを引き継げないのは、VBや、Windows
に限定された話ではないのでは？
極端に処理が遅い業務アプリは、データベースの設計自体に問題があり、
無駄にDB間でレコードをコピーしたり、テーブルのリンクが必要だったり
ということが多い気がする。
427:デフォルトの名無しさん
09/02/26 01:55:03
プロセス間のデータ共有なら共有メモリがあるよ
特に親子関係があれば、mmap ANON とかでお手軽極楽
スレッドのメリットは（スレッド間なら）高速にディスパッチ出来る点だね
heap だろうとなんだろうとメモリは全部共有されるというのは
メリットでもあるけど、デメリットでもあるかな。
バグの原因になりがちだよね
428:デフォルトの名無しさん
09/02/26 03:45:35
構造化されたデータを別プロセスと共有メモリ経由でやりとりするとして
c構造体ならまあなんとかなるんだが（いやそれでも大変だが）
c++クラスだとすんごいやりにくい
何かウマい方法あります？
受け渡し用にクラス作るのもアホらしいし・・・
変態的テンプレートでなんとかなるもんだろうか
それとも単なる通信バッファとしてしか使わない？
429:デフォルトの名無しさん
09/02/26 03:52:42
C++ならCの構造体も使えるんじゃ…。
430:デフォルトの名無しさん
09/02/26 04:07:16
そういうのはソケット使って単純化してる。
プロセス間共有メモリは後で環境や仕様が変わったときに
変更が大変だし流用も難しい。バグも入りやすい。
パフォーマンスを上げたいとか、よっぽどの理由でも
ない限り使われないんじゃないかな。
スレッドと違って>>428の言うデメリットもあるし。
ウマい方法はありません。
431:デフォルトの名無しさん
09/02/26 04:53:41
>>426
酷いミスリードだな。>424はマルチプロセスによるマルチタスクという技法がWindows向けでないと言っているように見えるが。
432:デフォルトの名無しさん
09/02/26 04:59:25
IE8はマルチプロセスですぜ
433:デフォルトの名無しさん
09/02/26 05:49:22
>>426
お前は誰なんだ
434:デフォルトの名無しさん
09/02/26 06:45:39
unixといえば今でもパイプをfork/execで分け合ってというイメージが強いな。
DBのコネクションは知らないがファイルハンドルならプロセス間で受け渡せる。
Windowsにもハンドルを複製して子プロセスに渡すオプションはあるのだが、
OS/2やNTは最初からスレッドをサポートしてたのであまり使われない。
435:426
09/02/26 17:42:01
>>425
ハンドルの複製に失敗しますた。orz 426=423です。
>>431
未だにWindowsがunixに劣っていると思っている原理主義者か、TRON房かも。
何を以ってunixを定義しているのか聞いてみたい。
>>434
ハンドルをコピーしたりは、MS-DOSにもあったかな。INT 28Hだか忘れたけど、
プリンタスプーラ用の割込使えば、一応擬似マルチタスクで一部のシステム
コールを呼べた。
デュアルコアやクァッドコアのCPUだと、マルチスレッド化すると理論上
2倍や4倍で動くと勘違いしているヤツもたまにいるよね。おまえのOSは
いったいいくつプロセスが動いていると思っているんだと、小一時間。(略
436:デフォルトの名無しさん
09/02/26 18:11:07
WindowsがUNIXより優れてると思い込んでるなら
まずはその幻想をぶち壊す！
437:デフォルトの名無しさん
09/02/26 18:40:58
>>436
上条さん乙。
つか、んな事誰も言ってないから。
438:デフォルトの名無しさん
09/02/26 23:22:19
マルチスレッドスレでマルチプロセス云々言ってる時に何の前提もなく
「マルチタスク」なんて言う奴は普通にスルーでいいと思うんだけど...
439:デフォルトの名無しさん
09/02/26 23:47:59
よ～し、おじさんもマルチプログラミングとかタイムシェアリングとかの古語を持ち出しちゃうぞ。
440:デフォルトの名無しさん
09/02/26 23:51:02
>>435
実質、4coreXeonのシステムだとOpenMPで4スレッドにして3.9倍速くなるけどね。
逆に、>435のCPUはOSをアイドル状態で動かすだけでどんだけ負荷喰ってるんだって話だな。
441:426
09/02/27 10:22:04
>>440
スレッドでどんなコードを走らせているか知らないけど、スレッド内で
アクセスするデータもコードも、CPU内のキャッシュに収まるくらい
小さなプログラムでもない限り、そういう結果はまずありえないと思うな。
それとも脳内キャッシュ？
442:426
09/02/27 10:43:15
非同期I/Oを使わずスレッド内でファイルI/O待ちしているとか、ネット
ワーク物理層の帯域幅に比べて通信速度が遅く、スレッド化でマルチ
セッション化できるといった、ある意味冗長な造りのプログラムなら
ありえるね。
OSのアイドル状態を持ち出すあたり、他に何個のプロセスがいつ走って
いるか考えていないのかな？(w
443:デフォルトの名無しさん
09/02/27 10:43:58
>>441
OpenMP知らないなら黙っていた方がいいと思うよ。