スレッドセーフかどうか自分のソースコードを見ても確認できないなどというのはおかしい。
潜在するロジック上のバグと違い、スレッド関連は明らかにヒューマンエラー。
>>943 ええっ!?
ロッキングロジック上の馬具は一体何?
ヒューマンエラー
結局シングルトンのインスタンスはどう返せばいいんだろ
class Singleton
{
private:
static Singleton instance;
Singleton();
public:
static Singleton getInstance();
};
Singleton::Singleton()
{
}
static Singleton Singleton::getInstance()
{
if(instance == null){
LOCK();
if(instance == null){
instance = new Singleton();
}
UNLOCK();
}
return instance;
}
DCLなんてしてないでイニシャライズとファイナライズをmainとかに書いとけばいいじゃん。
シンプルだし、最適化がどーのなんて悩まないで済むんだし。
それはシングルトンの場合でしょ。
それで済むときはそれで構わない。
# 但しシングルトンの時も、シングルトン間の初期化の順序を制御したい場合、
# 動的に確保されるシングルトンの場合はダメ。
またDCLはオブジェクトがある条件を満たした時に、
初めて行われるポインタメンバーの初期化などに必要。
>>942 > 最初から意識して作るしかないだろう
同一のインスタンスに対する並行アクセスはダメ、というケースはよく見るね
使う側からすると、下手にロックされても困る場合もあるから
ライブラリの設計は難しい・・・
過疎スレなのにそんなに早く次スレ立ててどうするの?
950過ぎたんだから別に何時立とうがどうでもいい話だな
スレッド立てる前にちゃんとロックしてね。
いやむしろマルチスレッドで
デッドロックする予感
食学者の哲事問題で
Pthread_mutex_lock(CriticalSection);
Pthread_mutex_lock(CriticalSection);
960 :
デフォルトの名無しさん:04/10/18 08:45:36
駄目な環境と宝刀#ifdefで区切ればいいじゃん
#ifdef LINUX
#include <linux/compiler.h>
barrier();
#elifdef XXX
XXX();
#else
#error Unknown system about memory barrier!!!
#endif
どうやら話が振り出しに戻ったようですな。
966 :
デフォルトの名無しさん:04/10/18 23:17:34
俺はもうひらき直ってインスタンス返却関数に毎回ロック掛けてます
KeMemoryBarrier()が使えるのはドライバのみ?
>947
2重チェックなんか無駄でしょう。
このメソッドを連続して複数回呼ぶとしたらそのつくりがおかしい
メソッド全体にロックかければ十分
>>969 すでにインスタンス作ったのにインスタンス取得の度にロックするほうが時間の無駄でしょうが
getInstanceをループの中で毎回呼ぶのですか?
そうはしないし、それならば多少時間がかかっても問題がない。
無意味な最適化をするとバグを混入する原因となりかねないのでシンプルにしたほうがいいと考えています。
>>971 >getInstanceをループの中で毎回呼ぶのですか?
ハァ?(゚Д゚)
>>getInstanceをループの中で毎回呼ぶのですか?
>
>ハァ?(゚Д゚)
ハァ?(゚Д゚)。Lock処理で何ミリセク処理時間が増えるか知らんが、その呼び出しが問題になるほど繰り返し呼び出すとしたら呼び出してるほうが問題なんだろうが。
キャッシュするなりすればいいという意味だろ。
>>973 なるべく透過的にキャッシュしたいね、という話をしているわけだが。
俺としてはガイシュツのTLSがいいとおもうね。
976 :
デフォルトの名無しさん:04/10/19 15:14:08
DCLもしらん厨房は早く寝ろ。
>>977 $ WRITE SYS$OUTPUT "VMS使いのおじいさんですか?"
>>977 DCL使ってプロジェクトを破滅に追いやるオマエ茂名。
980 :
デフォルトの名無しさん:04/10/20 11:53:49
windowsでもunixでもコンパイルできるマルチスレッドプログラムはどのように書けばよいのでしょうか?
Ruby!!!!!!!!!!!!
そーいや、なんでRubyなんだろうな。
まともな言語だって思ってたんだけど、2ch見てるとHSPと同じような位置にしか見えない。
C++なぞ問題外発言の所為?
スレッドをどのくらいまでなら作っても大丈夫なんですかね。
木構造の接点それぞれにスレッドを割り当てるプログラムで、
枝接点は、ほとんど何もしないラッパー的なスレッドで、
主な処理は、葉接点にあたるスレッドが行うというものですが、
重い葉接点スレッドの実行数を制限すれば、全体で数百〜千スレッド逝っても大丈夫でしょうか。
環境依存
>>983 >木構造の接点それぞれにスレッドを割り当てるプログラムで、
>枝接点は、ほとんど何もしないラッパー的なスレッドで、
>主な処理は、葉接点にあたるスレッドが行うというものですが、
まあ、話のタネに聞いておくが、
何でそんなものが必要なんだ?
>>982 アンチC++やアンチPerl色が強すぎてある意味宗教じみてた頃があったからかな?
今はどうなのか知らないけど
>>985 汎用的な処理を行うシェルのようなプログラムを作成しているのですが、
階層別にグループ化が必須なので。
で、スレッド暴走時の対処や、ある階層以下のすべてのスレッドに命令、セキュリティは?
とか考えると、ルートを一つにするよりも、全部スレッドにしたほうがいいかなと思いまして。
まあ、どっちにしろ最大スレッド数あたりを設定して、そこからあふれた場合はキューにためておいて、
スレッド数が減ってきたら、キューから読んでスレッド作成という動作を実装する必要がありますが。
スレッド必要な理由がよくわからんのですが・・・
selectやpollでwaitできないデバイスを扱うのに必要なんだよ。ボウヤ。
shellならprocess作って走らせるだけだからthreadは複数要らんってことなんじゃね?
pthread_barrier_init(&b, NULL, 8人);
pthread_barrier_wait(&b);
std::2ch << "1000ゲット!!" << std::endl;