- 1 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:26:16 ]
- マルチスレッドプログラミングについて語るスレ
■前スレ
マルチスレッドプログラミング相談室 その６
ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
■過去スレ
その１ ttp://pc3.2ch.net/tech/kako/997/997345868.html
その２ ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その４ ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その５ ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/
OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他突起する事項】
- 2 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:31:40 ]
- ■関連スレ・関連性の高いスレ
【マルチコア】並列化について語る【使いこなせ】
ttp://pc11.2ch.net/test/read.cgi/tech/1137540671/
pthread地獄 part 2
ttp://pc11.2ch.net/test/read.cgi/unix/1166620307/
ネットワークプログラミング相談室 Port21
ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
- 3 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 19:32:51 ]
- >>1-2
乙
- 4 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 12:40:51 ]
- これは関連スレじゃ無し？
OpenMPプログラミング
pc11.2ch.net/test/read.cgi/tech/1102483474/
- 5 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 12:50:44 ]
- じゃこれも
Message Passing Interface (MPI) 統合スレ
pc11.2ch.net/test/read.cgi/tech/1099819556/
- 6 名前：デフォルトの名無しさん [2008/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 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 21:11:24 ]
- boost::shared_ptr<Thread> th(new Thread);
boost::thread(boost::bind(&Thread::operator(), th));
- 8 名前：6 mailto:sage [2008/07/09(水) 22:44:08 ]
- 7が動くのは理解したのですが、ありがたみがいまいちわかりません。
この場合thはスレッド処理が完了したこと（つまりth.reset()を呼ぶタイミング）を
どうやって知るのでしょうか。
- 9 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 23:01:53 ]
- いや…、どうやっても何もThreadのデストラクタが呼ばれるだろ。
ていうか何がしたいのさ？
スレッド作ってあとは関知せずという無責任なマネをしたいのか、
メインスレッドと同期して何かをしたいのか。
- 10 名前：6 mailto:sage [2008/07/09(水) 23:11:20 ]
- 処理の種類に応じてThreadA、ThreadB、...（単一のThreadクラスを継承）を用意しています。
で、本体はThread*を1つ管理していて（p_とします）、
処理が必要になった時点でp_.reset(new ThreadA) のようにします。
その際に他のスレッドが処理中かどうかをp_!=0のように判定したいなと。
- 11 名前：6 mailto:sage [2008/07/09(水) 23:14:32 ]
- ありゃ、なんか>>10は>>6の単なる繰り返しですね…。
何をしたいかというと、いくつかのマルチスレッド処理を
排他でとっかえひっかえ行いたいという感じでしょうか。
- 12 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 23:23:24 ]
- まあ、普通に thread pool 使えばいいんじゃね。
- 13 名前：13 mailto:sage [2008/07/09(水) 23:36:47 ]
- 教えてください。
A.cというファイルにグローバル定義で定義した
volatile変数をB.cというファイルで参照したい場合、
volatile extern int hoge;
とかでいいのでしょうか？
- 14 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 23:44:57 ]
- >>11
実行中のワーカスレッドが存在する場合にどういう選択肢があるのか
(終了を待ってから新しいスレッドを起動する/途中でも終わらせて新しいスレッドを起動する etc..)
によっても実装の仕方は変わってくると思うんだけど、どうだろう。
- 15 名前：6 mailto:sage [2008/07/10(木) 04:26:36 ]
- >>14
今のところ、実行中のワーカスレッドが存在する場合には、
「別のスレッドを実行中だからスレッド終了まで待ってね」
と表示して何もせずにreturnという仕様です。
（>>6の方法で動いてたのですが、たまたま運が良かっただけですね）
- 16 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 07:19:10 ]
- >>13
B.cでその前にstatic volatile int hoge;と書いてなければOK
>>7
これって、スレッド終了より早くthがスコープ抜けても問題ないの?
>>6がやりたいことはMFCのCWinThreadのbAutoDeleteでしょ。
- 17 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 23:17:00 ]
- >>16
shared_ptrでラップされてて、それを保持した
functorがスレッド終了時に破棄される。
そのタイミングでthの指すインスタンスも破棄される・・・・多分。
- 18 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 23:17:19 ]
- MFCは平気でdelete thisしてる。
ThreadManagerまで作ったのなら、()を直接呼び出すのでなくて
()を呼び出した後でメモリ解放するラッパーをサブスレッドで実行すればいい。
ついでにshared_ptrの操作前後で排他制御が必要。
- 19 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 00:29:11 ]
- タイムアウト監視中にシステム時刻が変更される可能性について
意識してない人が大杉な気がする。そういう脆弱なコードをいっぱい見てきた。
現実的な例として、ホストとの接続時に時刻の同期が要求される某FA分野プロトコルを
使ったシステムで、同時にハードとの通信のタイムアウトを監視してたら
とても愉快なことが起こり得るわけだ。
つまり、pthread_cond_timedwaitの仕様は困るってこと。
非標準の相対時間によるwaitをサポートしないPthread環境で
この問題を解決する方法が分からない、というかできないでFA?
- 20 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 01:17:00 ]
- 放置！
- 21 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 03:25:52 ]
- ホスト時刻と端末時刻の差を管理すればいいだけじゃない
- 22 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 03:43:50 ]
- ・時刻同期してから絶対時間に依存する処理を開始する
・時刻同期を徐々に（ntpd的に）行う
- 23 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 04:31:24 ]
- >>21>>22
もしかしたら、俺がどうしてもUnixでシステムを動かす必要に迫られてると思って、
一生懸命解決策を考えてくれたんだろうか？だったらごめん。
Windows使ってます。
俺が知りたいのは、特定の仕様のシステムを実現する方法じゃなくて、
他のプログラムが何していようが、
ユーザが好き勝手に時刻を変更しようが、
現在からN秒以内に条件が成立しなければ、アウトという監視は本当にできないのかってこと。
Pthread標準の枠内で。
時刻をいじってるプログラムと密に連携したり同期とれるとか、
そんなこと当てにできないし、したくもない。
- 24 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 05:43:29 ]
- windowsでpthreadなの？よくわからんがTickCountじゃだめなのかな。
- 25 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 05:51:01 ]
- 普通はハートビートを刻む液晶系のクロックと、カレンダ時計があって、
sleepだのwaitのタイムアウトの監視は前者、
カレンダ時計はcronのようなもっとスパンの長いスケジューラで使っていると思ったのだが、
pthread_cond_timedwaitはカレンダ時計を使ってるのかな。
- 26 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 06:50:42 ]
- pthread_cond_timedwaitは困ったことに絶対時間指定なんだ。
利用者にも実装者にも不評で
pthread以外の同種のAPIで待機時間でなく絶対時間を
使っているのは見たことがない。
- 27 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 09:49:47 ]
- まあAPI仕様に無い以上無理なんだろう。勉強になりますた。
苦しい対処だが1秒タイムアウトをN回繰り返せば誤差1秒でタイムアウトできる、かな。
あとWindowsならスレッド生成だけpthread使って、同期はWin32 APIでするとか
- 28 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 10:48:39 ]
- 情報小出し君にはレスしても無駄だと分かった
- 29 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 10:57:06 ]
- >>27
Windows で pthread ?
なんでそんなことしたいのかを書かないと、単なるバカにしか見えないよ。
あと、pthread_cond_timedwait がダメダメなら、setitimer でシグナル
もらうとかすればいいんじゃないのか？
- 30 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 11:09:52 ]
- ttp://sourceware.org/pthreads-win32/ のソースを確認したのだが、
絶対時間をすぐさま待機時間（ミリ秒）に変換。
最終的にWaitForMultiObjectのtimeout指定で使ってた。
- 31 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 11:12:15 ]
- Win32と言ったりpthreadと言ったり、答えようがない。
Win32には延長付のタイムアウトのAPIや時刻に影響しない経過時間を計測できるAPIがあるのに残念だったな。
- 32 名前：27 mailto:sage [2008/07/12(土) 11:18:17 ]
- >>29
俺は>>27だが、>>19=>>23とは別人だ。
もともとの>>19がWindowsでpthreadのようだけど、企業でそういう指定があるから
だと推測した。それで「使ってるフリして回避する方法」として、同期だけWin32したら?
と言ってみた。
- 33 名前：19 mailto:sage [2008/07/12(土) 13:00:21 ]
- >>19=>>23だが、なんか混乱させてるな。
俺が現実に直面してる仕事なんかに関係なく、
このpthread_timedwaitの仕様どうなの？って話がしたかっただけ。
俺でも分かるような欠陥が本当にメジャーな標準規格にあるのか
疑問だったので、もしかしたら、今のPthreadの枠内で簡単に解決する方法があるのかと思った。
それも聞きたかったことの一つ。
Pthread本を見ると、絶対時刻が使われていることのメリットしか書かれてないけど、
俺としては、相対時刻でタイムアウト監視できるAPIの方がよほど必須のように思えたので。
- 34 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 14:15:09 ]
- tasksetの使い方教えてください。オプションとか…。
スレッド１→コア１
…
スレッド４→コア４
みたいに割り当てたいのですが、
tasksetじゃできないですかね…？
ちなみにlinuxでopenmpでやろうかと思っています
- 35 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 14:21:58 ]
- で、このスレとしてはPthreadではできないという結論になると。
>>26 C++ boostも絶対時間だったような。
- 36 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 14:36:44 ]
- >>34
そうしたい理由を先に言ったほうがいいよ
まさか
「割り当てられないとしたらその仕様どうなの？って話がしたかっただけ」
じゃないよな
- 37 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 14:51:09 ]
- >>35
最新版ではabstimeとreltime向けに別々の時間クラスが定義されて
timedwaitはオーバーロードされてる。
例によって、実装はテキトーに変換してるだけなので、
ネイティブに近い方のオーバーロードだけは信頼できるってかんじかな。
- 38 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 15:29:11 ]
- >>37
信頼できるかどうかはOS次第だと思う。
どんなラッパー仕様だろうと最終的にはOSのAPIを呼び出すことになるので
>>30は当然のこと。もしPthreadのプログラムインターフェースしか提供されて
いないOSなら信頼はできない。
- 39 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 02:16:06 ]
- pc11.2ch.net/test/read.cgi/unix/1166620307/69
笑った
- 40 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 03:48:14 ]
- >>19はPthreadの絶対時間指定によるデメリットを仕様欠陥と(あちこちで)指摘してるだけだろ。
一貫してるからいいんじゃね?
例がアレなので相手にされてないようだけど「システム時刻を修正されるとまずい」ってのは
事実で、時間が巻き戻らない前提ってのは無茶苦茶だ。SIベンダがBtoBで構築するシステムなら
ともかくフリーソフト作れねーぞ。
しかも理由が「絶対-相対の変換の足し算中にプリエンプションが発生すると待ち時間がずれる
から」ってのは納得できねー。タイムアウト時間にごく僅かな誤差が出ることに問題あるとは
思えないし、責任をアプリに押しつけただけなのは基盤として問題だろ
- 41 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 05:49:24 ]
- >>19は>>23の書き込みが余計だったな、誤解を招いた。
続けるなら>>39のUNIX板のがいいじゃないか。
- 42 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 15:02:30 ]
- >>40
え〜っと、本人乙でいいかな。
- 43 名前：デフォルトの名無しさん [2008/07/13(日) 23:27:07 ]
- マルチスレッド対応にしたら
デュアルコアのCPUを両方とも使って処理してくれるの？
- 44 名前：デフォルトの名無しさん mailto:sage [2008/07/13(日) 23:33:38 ]
- >>43
普通はOSまかせ。
OSはコアをまんべんなく使おうとするから普通は両方使ってくれるが、
他のプログラムが１つのコアをめいいっぱい使ってたら、
同じコアに振られることもある。
- 45 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 08:20:00 ]
- ｻﾝｸｽ
- 46 名前：デフォルトの名無しさん mailto:sage [2008/07/17(木) 01:20:09 ]
- 自演乙
- 47 名前：デフォルトの名無しさん [2008/07/17(木) 02:11:04 ]
- 自演乙厨ｗ
- 48 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 00:32:11 ]
- void f()
{
static struct Hoge hoge;
pthread_mutex_lock();
///hogeにアクセス
pthread_mutex_unlock();
}
こんな感じのコードあってstaticだから安全だって譲らない
Ｋ主任って糞がいます助けてください
- 49 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 01:00:04 ]
- Hogeがコンストラクタを持つの？
- 50 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 01:01:55 ]
- >>49
Ｃ99ですＣ＋＋じゃないです
- 51 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 01:11:21 ]
- K主任も災難だな
- 52 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 01:17:01 ]
- >>48
どういう危険があると思うの？
- 53 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 02:50:08 ]
- >>48
少なくともそこで示されている記述だけじゃ
問題のあるソースだとは思えん。
pthread_mutex_lock()とかの引数に渡されているmutexが
非staticなauto変数とかだったらダメだけど。
- 54 名前：デフォルトの名無しさん mailto:sage [2008/07/18(金) 14:39:31 ]
- hogeのアドレスを外部に漏らして、そっちはmutexなしでアクセスとか?
- 55 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 17:07:42 ]
- 安全って理由が staticだから でmutexはあってもなくても関係ないって
K主任が主張してあるのであれば、これはもうどうしようもない
- 56 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 17:19:44 ]
- ワロタ
- 57 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 18:39:06 ]
- つまりこういうこと？
>>48って糞が粘着しています助けてください Ｋ主任
- 58 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 20:42:06 ]
- >>48
どんな危険があると考えてるのな？
hogeのポインタを外に出さない限りmutexはいらないと思うけど。
- 59 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 21:04:23 ]
- >>58
fが複数スレッドから呼ばれるとしたら、hogeをどうするのかによるね。
- 60 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 21:11:22 ]
- >>59
複数スレッドで呼ぶとどうなるのでつか？
- 61 名前：デフォルトの名無しさん mailto:sage [2008/07/19(土) 22:46:35 ]
- Ｋ主任が見てるようなので退散します・・・
- 62 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 02:19:01 ]
- strtokとstrtok_rの違いを考えろ
- 63 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 03:51:23 ]
- ネタを振った責任として>>48は、何が問題があると思うのかくらいは
説明して欲しいな。
- 64 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 08:50:23 ]
- >>63
Ｋ主任の糞っぷりです
- 65 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 16:35:37 ]
- >>60
hoge がstaticだから、hogeのコンストラクタが（あれば）起動時
一度だけ動くのみ。
だから排他部分の外で宣言されていても安全、ってことだろう。
とはいえstaticじゃ無かったとしても何か危険があるかというと
よくわからんから、staticだから安全ってのはなんか変な主張
という気がしなくもないな。
- 66 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 16:54:53 ]
- アドレスを外部に漏らしてなければ、この関数からしか
アクセスできない。そこに排他がちゃんとかかってるか
ら大丈夫だろ？ って言うことだと思うが。
- 67 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 17:24:19 ]
- C99って言ってるから(>>50)コンストラクタはないんだが、
仮にc++だとすると
>>65
>hoge がstaticだから、hogeのコンストラクタが（あれば）起動時
>一度だけ動くのみ。
違うぞ。
static struct Hoge hoge; の行に到達したときに、
一度だけ実行される。
その「一度だけ」のフラグが排他されていないことがあるだろう、
というのが起こりうる問題。
- 68 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 17:59:36 ]
- 仮にC++だとするとこうするべきってことですか？
pthread_mutex_lock();
static struct Hoge hoge;
///hogeにアクセス
pthread_mutex_unlock();
- 69 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 18:08:21 ]
- 前スレ850くらいからその話題が出てるわけで
- 70 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 19:39:41 ]
- DCLでいいよ。
- 71 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 22:49:34 ]
- そこで-fthreadsafe-statics
- 72 名前：デフォルトの名無しさん mailto:sage [2008/07/20(日) 23:29:57 ]
- そんな実装依存じゃＫ主任に笑われるぞ
- 73 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 08:24:43 ]
- ハードのことはよく分からないのですが、同じメモリアドレスに複数のコアが同時アクセスすると
なにか問題が起こることはあるのでしょうか？
例えば整数型のグローバル変数aを作り、
スレッド1ではそれを読みこみ加算します。スレッド2ではそれを読み込み減算します。
シングルコアでは物理的に、本当の意味での同時アクセスはありえないので
意図した結果が得られないとしても、ハード的に不具合はないですよね。
仮にスレッド1ではreadのみ、スレッド2ではwriteのみだと何の問題もないはずです。
これがマルチコア環境だと、スレッド1がread, スレッド2がwriteのみだとしても
同メモリアドレスに各コアが本当の意味で同時アクセスしますよね。
こういうことはやってはいけないのでしょうか？
- 74 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 08:44:31 ]
- いや、同時アクセスしてもハード的な問題は起きない
writeの結果がreadに反映されるかされないかの問題でしかない
- 75 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 11:26:02 ]
- >>73
それが同じCPU内の別のコアなら、キャッシュ管理かどっかで調停するから問題ない。
それが違うCPUのコアなら、メモリ管理かどっかで調停(ｒｙ
- 76 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 11:35:00 ]
- コア毎のキャッシュにヒットしなかったと仮定すると、
最終的に、競合するバスアクセスが発生するわけだが、
その時にはバスのアービタが調停する。
- 77 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 16:34:22 ]
- >>74-76
ありがとうございます。
調停(アービトレーション？)というのは調べても詳しくは分からなかったのですが、
同時アクセスするような状況で排他処理をしてくれるということでしょうか
- 78 名前：デフォルトの名無しさん mailto:sage [2008/07/29(火) 16:38:24 ]
- ハード的な話なのでソフト的な排他処理とはちょっと違う希ガス。
- 79 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 02:06:51 ]
- ハード屋の無知はおいておくとして、信用するなよ。
マルチコアとシングルコアの違いは、スケジューラを動かす数が
違うのが一番大きい。あるスレッド（プロセス）は、基本的に１つの
CPU上で動作する。
当然、複数のスレッド（プロセス）間の排他は必要だが、アプリ上
はたいして変わらない。マルチコアでは、アトミックな操作のための
バスを占有するような命令が追加されているだけ。
- 80 名前：デフォルトの名無しさん mailto:sage [2008/08/01(金) 12:45:08 ]
- >マルチコアとシングルコアの違いは、スケジューラを動かす数が 違うのが一番大きい。
誰もそんな話してないしｗ
>あるスレッド（プロセス）は、基本的に１つの CPU上で動作する。
間違ってるし
ロードバランスとか考え出すと頭が痛くなるが，まぁ
Read-Write-lock みたいなことをやってると思っとけば
- 81 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 14:33:08 ]
- 基本的にって言ってるから何でもあり。
- 82 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 18:46:05 ]
- て言うかある一瞬を言ってるのか、スレッドの一生を言ってるのかわからんから
間違ってるか判断できない。
- 83 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 00:19:01 ]
- 突っ込み所が違うだろ。
>>73に対して>>74〜>>76が問題ないって言ってるのにそれを否定してるんだぞ。
メモリの同時アクセスは複数プロセスでも起こるので、すべてのメモリアクセスは
明示的にバスの排他命令を使用する必要があるな。
- 84 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 00:39:01 ]
- >77はこれでも読んでみれ
ttp://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%83%A1%E3%83%A2%E3%83%AA
- 85 名前：デフォルトの名無しさん mailto:sage [2008/08/03(日) 00:49:09 ]
- >>79 の書き込みは、肝心なところがちゃんと書いてないから
正しいとか間違ってるとか言うことはできない。
まあ、>83 の書き込みも似たようなものだが。
- 86 名前：デフォルトの名無しさん [2008/08/24(日) 23:25:42 ]
- RT-Linuxでマルチスレッドで組んでいます。
スケジューリングポリシーはSCHED_FIFOです。
pthread_condを使った排他を考えているのですが、
pthrad_cond_wait()を複数スレッドで呼び出した後に
pthrad_cond_broadcast()を呼び出した時の動き出すスレッドの
順番がスレッドの優先度順になっていません。
(ちなみにsunのページにはブロック解除の順番は不定と書いてありました。)
そもそもやりたい事が
ttp://www.hanecci.com/pukiwiki/index.php?Programming%2FMultiThreading
の「リードライトロック」のような事なのですが、
優先度順に動き出させるようにするにはどうしたらいいですか？
よろしくおねがいします。
- 87 名前：デフォルトの名無しさん mailto:sage [2008/08/24(日) 23:59:16 ]
- 写生してえ。
- 88 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 01:57:04 ]
- だから、スケジューラの実装依存になるようなプログラムを組むなと
なんど言ったらわかるのだ・・・。マイナーバージョンが変わっても、
挙動かわるぞ。
- 89 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 02:19:03 ]
- 何のためのRT-Linux
- 90 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 21:28:31 ]
- >>86
pthread_cond_waitに入るときに、クリティカルセクション内で
現在待ちに入っているスレッドの優先度をメモっておいて、
pthread_cond_broadcastで起きたときに、クリティカルセクション内で
自分より高い優先度のスレッドが待ちに入っているなら、
何もせずに再びpthread_cond_waitに入る、じゃだめなのかな。
必ずその優先度の高いスレッドも起こされるはず・・・だと思う。
やばいタイミングとかあるか・・・な？
- 91 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 21:48:00 ]
- CPU稼働率落ちそうだな。
- 92 名前：86 [2008/08/25(月) 22:44:47 ]
- 解決した。
pthread_condとかつかわずに セマフォで普通に組めるのね。
ありがと。
>>87
うん
>>88、89
そこでヒントがほしかった＞＜
>>90
簡単な仕組みにしたいっすね。
>>91
ですね
- 93 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 23:33:52 ]
- 簡単にCreateThreadできるようになるクラスとかないかな
- 94 名前：デフォルトの名無しさん mailto:sage [2008/08/25(月) 23:43:39 ]
- boost::threadとか？
- 95 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 15:11:50 ]
- データ処理部分とHDDから読み込み&書き込み処理部分ってスレッド分けた方が効率上がると思うんですが、
HDDのIO部分自体は分けないで一つのスレッドでやった方が効率いいですよね？
2つの異なるHDDから読み込み＆書き込みする場合はHDD毎にスレッド作った方が効率いいですよね？
間違ってたら指摘お願いしますm(_ _)m
- 96 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 15:21:44 ]
- >>95
ドライバはカーネルが動かす。従って、CPUが複数(或いは複数コア)あるなら
ユーザアプリとは並列に動ける。おまけに、ディスク自体にもバッファがあるから普通は余り意識しない。
まして一般的にディスクの方が圧倒的に遅いから、HDD毎にスレッドを作るなんて事はしない。
- 97 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 15:23:45 ]
- 追記です。二つ目の質問は
「一つのHDDから複数のデータを読み書きするとき、データごとに別スレッドにはしないべきか」と言う意味です
宜しくお願いします
- 98 名前：デフォルトの名無しさん [2008/09/09(火) 15:33:43 ]
- HDDは遅いから複数スレッドの方がいい
HDD1が終わるまで待っている時間が無駄
- 99 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 15:38:58 ]
- 早速回答ありがとうございます！
しかし>>96と>>98の言っていることが逆に見えて混乱しています
たとえカーネルが実際のIO等を行ってるとしても、読み込み終わるまでアプリは待機しますよね？
IO毎にスレッドを分ければその間CPUはアイドル状態にならずに効率が上がるかと思うのですが・・・
しかし、同じHDDで読み書きするデータごとにスレッドを分けるのは流石にやりすぎですよね＾＾；
- 100 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 15:43:03 ]
- >>99
>95はI/Oに限定した話じゃないの? I/Oしかやることがないならスレッド分けたって待つだけじゃん。
処理とI/Oを分けるかって話なら処理がI/Oに依存しないで済むなら分けておいたら? ってことになる。
|
 |
