C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[12]: マルチスレッドのデータ競合


(過去ログ 127 を表示中)

[トピック内 15 記事 (1 - 15 表示)]  << 0 >>

■75443 / inTopicNo.1)  マルチスレッドのデータ競合
  
□投稿者/ hikaru (1回)-(2015/03/25(Wed) 13:40:54)

分類:[C/C++] 

class Data
{
public:
int getData( void )
{
return m_data;
}
void setData( int data )
{
m_data = data;
}

int m_data;
int m_msg;
int m_count;
bool m_IsFlag;
};

Data g_Data;
int g_num = 0;

// 処理スレッド1
UINT WINAPI ThreadProc1( void * )
{
// 例1 グローバル変数から読み込み
int a = g_num; // データの読み込みだけなので OK
// 例2 グローバル変数から読み込み
int b = g_num; // データの読み書きが同時発生 NG
// 例3 メソッド
int c = g_Data.getData(); // ?
// 例4 switch文
switch( m_msg ) // ?
// 例5 if文
if ( m_IsFlag ) // ?
// 例6 for文
for( int i=0; i<m_count; ++i ) // ?
}

// 処理スレッド2
UINT WINAPI ThreadProc2( void * )
{
// 例1 グローバル変数から読み込み
in a = g_num; // データの読み込みだけなので OK
// 例2 グローバル変数に書き込み
g_num = 1; // データの読み書きが同時発生 NG
// 例3 メソッド
g_Data.setData( 100 ); // ?
// 例4 switch文
m_msg = 1; // ?
// 例5 if文
m_IsFlag = true; // ?
// 例6 for文
m_count = 10; // ?
}

古い環境です。
Visual C++6.0 Enterprise
Windows98SE

初めての投稿です。よろしくお願いします。

今までのシングルスレッド(メインスレッドだけ)とは違いマルチスレッドは同時変数アクセスの
データ競合を常に意識してプログラミングしなといけません。

例えば count ++; をc++言語で書くと一行ですがCPU内部では下の大まかに三つの動作に
分割されて処理されていますが、その間にデータ共有をしている変数がスレッドの割り込みの
発生に合ってしまうとデータ競合になってしまいデータが破損してしまいます。

1 メモリからCPU内部のレジスタに読み込み
2 レジスタで計算
3 レジスタからメモリに書き込み

この上の考え方を踏まえると、

例1と例2は、イコール(=代入)を使用して書き込みと読み込みを直感的に操作しているので感覚的に
安全か危険が分かり易いのですが他の例では、片方はイコールを使用して書き込んで、もう片方では
イコールを使用せずの状態ですが、こいう場合はデータ競合に当るのでしょうか?
なるべく、クリティカルセクションとインターロック系は使用せず設計したいのでよろしくお願いします。
その他にもデータ競合してしまう要素がありましたら教えて下さい。

できれば下の?に何か簡単なコメントを頂けたら嬉しいです。
( ※処理スレッド1(ThreadProc1)と処理スレッド2(ThreadProc2)が同時に実行された場合 )

< 処理スレッド1の例1と処理スレッド2の例1 >
両方とも読み込みなのでOKです。

< 処理スレッド1の例2と処理スレッド2の例2 >
同一変数に対して書き込みと読み込みを同時に行っているのでNGです。

< 処理スレッド1の例3と処理スレッド2の例3 >
?
< 処理スレッド1の例4と処理スレッド2の例4 >
?
< 処理スレッド1の例5と処理スレッド2の例5 >
?
< 処理スレッド1の例6と処理スレッド2の例6 >
?

引用返信 編集キー/
■75447 / inTopicNo.2)  Re[1]: マルチスレッドのデータ競合
□投稿者/ 774RR (246回)-(2015/03/25(Wed) 14:19:05)
基本的にマルチスレッド配下で「同一グローバル変数」を複数スレッドで同時に使うのであれば、
必ず排他が必要と考えていい。

> できれば下の?に何か簡単なコメントを頂けたら嬉しいです。
例1は無条件でOK
例2例4例5例6はOKともいえるしNGともいえる(要望というか前提条件というか次第)。
例3は get/set 自体で排他してるかどうかで違う

とりあえずこのスレッドを紹介しておく
http://bbs.wankuma.com/index.cgi?mode=al2&namber=65737&KLOG=111

引用返信 編集キー/
■75456 / inTopicNo.3)  Re[2]: マルチスレッドのデータ競合
□投稿者/ hikaru (2回)-(2015/03/26(Thu) 14:02:12)
教えて下さった先のリンクを拝見させて頂きました。

メモリバリアや volatile など興味深い知らない単語が出てきて解読に時間が掛かりましたが
色々と私なりに調べた結果 VC2003以前は、volatile だけではメモリバリアは不十分見たい
でしたけど VC2005以降は volatile だけでメモリバリアの面倒をみてくれるらしいのでので
一安心しました。

そして、単純な変数の読み書きはアトミック化は保障されている見たいなので ( 64bit 変数は
アトミックじゃない見たいだけど ) 複雑な処理が挟む場所は、ロックした方が無難だと判断しました。

どうも、ありがとうございました。
解決済み
引用返信 編集キー/
■75460 / inTopicNo.4)  Re[3]: マルチスレッドのデータ競合
□投稿者/ 774RR (248回)-(2015/03/26(Thu) 14:43:32)
そもそも1つのグローバル変数を操作するのであればマルチスレッド化する理由/メリットが無いので
ロックを多用しながらマルチスレッドを使うくらいならシングルスレッドのままがいい。
手間の割りに得られるもの(性能アップの程度)が少なすぎる。俺ならやらない。

以下蛇足。

「競合」ってのは定義次第。
例示した先のリンクでも解説してるけど y=x; に対して
・ y が更新されるタイミングで
・既に x は新しい値になっているかもしれない
これは競合なのかそうでないのかは案件で違う。

今回の例題2
g_num=1; と x=g_num; が同時に実行されたとき
・ x に求められるものは何なのか ( 1 なのか 過去の値なのか ) は案件で違う

本当は g_num 1つだけが更新されるんぢゃなくて g_num 個数のデータが一緒にあるんぢゃないの?
int data[MAXCOUNT]; のうち g_num 個が有効、みたいな感じで。
もしそうなら、ここで求められるのは「複数リソースを不可分に更新する」であるから排他が必須だ。

そうではなくて実際に atomic アクセス可能な変数1個が更新されるだけで
旧値を読んでも新値を読んでも問題ないってことならロックはいらない。
# ここでメモリバリアの話が出てくるわけだけど
# 特に複数の変数の値を変更して読む際の観測順とか

atomic アクセスできない変数を同時読み書きする場合はロックがいるよ (64bit 変数とか)
atomic アクセスできないなら旧値でも新値でもない変な値が得られる可能性がある。

# 解決済みを維持しておこう
解決済み
引用返信 編集キー/
■75464 / inTopicNo.5)  Re[3]: マルチスレッドのデータ競合
□投稿者/ yoh2 (7回)-(2015/03/27(Fri) 00:56:32)
> 色々と私なりに調べた結果 VC2003以前は、volatile だけではメモリバリアは不十分見たい
> でしたけど VC2005以降は volatile だけでメモリバリアの面倒をみてくれるらしいのでので
> 一安心しました。

VC2005以降で volatile 使った場合でも、フルバリアとなるわけじゃないから注意。

VC2013のマニュアルだけど、
https://msdn.microsoft.com/en-us/library/12a04hfd.aspx
の、Microsoft Specific の節参照。
過去に C# の volatile について
http://bbs.wankuma.com/index.cgi?mode=al2&namber=74661&KLOG=126 の No. 74896
に書いたけど、VC++ (で、コンパイラオプションに /volatile:ms を付けた場合 ※;
ARM 以外ではデフォルト) もこれと同様。

> - volatile フィールドの読み取り:それ以降のメモリ参照より先に行われることが保証されている。いわゆる acquire バリア。
> - volatile フィールドへの書き込み: それ以前のメモリ参照の後に行われることが保証されている。いわゆる release バリア。

となってます。
ある volatile 変数 x と y があって、x に何か代入した後 y を参照する、
という順序を保証したい時には volatile では不十分。

※ もう一個のオプション /volatile:iso (ARM のデフォルトでもある) だと
volatile はスレッド間の同期に使ってはならないことになってます。
解決済み
引用返信 編集キー/
■75478 / inTopicNo.6)  Re[4]: マルチスレッドのデータ競合
□投稿者/ hikaru (3回)-(2015/03/28(Sat) 06:22:59)
どうも、解決済みとしたにもかかわらず気にかけてくださってありがとうございます。

-----------------------------------------------------------------------

774RR さん

>>そうではなくて実際に atomic アクセス可能な変数1個が更新されるだけで
>>atomic アクセスできない変数を同時読み書きする場合はロックがいるよ (64bit 変数とか)
>>atomic アクセスできないなら旧値でも新値でもない変な値が得られる可能性がある。

申し訳ないのですが "atomic アクセス"と言う表現がちょっと私には分かりずらいのですが
何せ、アトミックと言う単語も最近知った言葉なので、お手数をお掛けして申し訳ないのですが
そこだけニュアンスを変えて貰えたらありがたいのですがよろしくお願いします。

※アトミック : それ以上細分化する事ができない処理の事ですよね?


CPU の内部動作について質問があります。

< シングルコアでメインスレッドとサブスレッドの2つのスレッドが起動中の場合 >
※分かりやすく説明する為にアセンブリ言語で表記しました。

メインスレッド
{
mov eax, 1 // 命令コード
}

サブスレッド
{
mov eax, 2 // 命令コード
}

よくスレッドのメモリ競合で説明される時に、同時という言葉を多くのサイトでも見受けられるので
すが、それは本当の同時に1命令コードを CPU は実行( 計算 )できるのか、それとも同時に見え
て交互に並列に実行しているのか、だとしたら下の文章になります。

最低 1命令コードが終わらない限り、例え複数のスレッドが割り込んで来たとしても今現在の
命令コードが終了しない限り次のスレッドの命令コードに移行する事はできなく、割り込んで来た
スレッドは現在実行中の命令コードが終了するまでそこで待機するのでしょうか?
ちょっと上手く伝わったか心配ですがよろしくお願いします。

-----------------------------------------------------------------------

yoh2 さん

volatile の情報をありがとうございます。

※Wikipedia のメモリバリアから一部抜粋
#開発者によっては、コンパイラによる並べ替え問題を防ぐ必要があるときには
#アセンブリ言語を使用する者もいる。

とあるのですが、私はアセンブラ言語の知識が少々ありますので勝手に最適化されたら
困る場所は、アセンブラでコードを書けば順序を保証できるのでしょうか?
よろしくお願いします。


引用返信 編集キー/
■75479 / inTopicNo.7)  Re[5]: マルチスレッドのデータ競合
□投稿者/ 774RR (249回)-(2015/03/28(Sat) 08:01:59)
とりあえず 32bit CPU を考えることにする。マルチコアでもシングルコアでもいい。

> ※アトミック : それ以上細分化する事ができない処理の事ですよね?
OK!

32bit 変数 foo が RAM 上に配置されるとして
foo=1; に対しては mov [foo], 1 が生成されるので atomic
if (foo==2) に対しては mov eax,[foo]; cmp eax, 2; なので atomic
++foo; に対しては mov eax,[foo]; (*A) inc eax; (*B) mov [foo], eax; なので non-atomic
(*A) (*B) 地点でタスク・スレッドが切り替わり、切り替わった先スレッドで foo を操作すると
このスレッドに戻ってきたときに、切り替わった先スレッドで代入した値を壊してしまう。

64bit 変数 bar が RAM 上に配置されるとして
bar=1; は mov [bar].lo, 1; (*C) mov [bar].hi,0 となるので non-atomic
if (bar==2) に対して mov eax,[bar].lo; (*D) mov edx,[bar].hi; cmp ... なので non-atomic
(*C) (*D) 地点でスレッドが切り替わり、切り替わった先スレッドで bar を
・読み込もうとしても lo しか変化していないので値が壊れている
・書き込んだら、戻ってきたとき lo は変化しないのでやはり値を壊してしまう

って理解でまず問題ないだろう。
なので「原理的に atomic になるはずのない処理」はアセンブラで書いても問題を回避できない。

同時性については厳密な話を始めると超難しい。
「何が同時なの?」「そもそも同時の定義って何」あたりの合意がないと話自体がすれ違う。

さわりだけなら
マルチコアな CPU なら真に同時に実行されうるよ。
コア1 : mov eax, [foo]
コア2 : mov [foo], eax
問題は [foo] ってどこ?というあたりで L1 cache なのかメインメモリなのか・・・・
普通は、メインメモリぢゃないから メモリバリアが必要になってくる、って話だ。

引用返信 編集キー/
■75480 / inTopicNo.8)  Re[5]: マルチスレッドのデータ競合
□投稿者/ yoh2 (8回)-(2015/03/28(Sat) 16:05:31)
> とあるのですが、私はアセンブラ言語の知識が少々ありますので勝手に最適化されたら
> 困る場所は、アセンブラでコードを書けば順序を保証できるのでしょうか?
> よろしくお願いします。

メモリフェンスを適切に使わなければ、ゴリゴリアセンブラで書いても
CPU が勝手に行う並べ替えを防げませんので不十分です。

例えば、以下のふたつのスレッドの処理を考えてみます。
各 mov は atomic なので、ふたつの mov が別々の CPU で真に同時実行
されたとしても、 mov がメモリを操作している途中に他の mov が
割り込んで半端な結果になってしまう、といったことはなく、必ず単純に
順序付けて考えることができます。

※ [x], [y] の初期値は共に 0 とする。

スレッド1
1: mov [x], 1
2: mov [y], 1

スレッド2
3: mov eax, [y]
4: mov ecx, [x]

上記のふたつのスレッドが異なるコアでほぼ同時に実
行された場合、各命令の実行順と、その結果として得られる
eax, ecxの内容は、メモリオーダリングを考慮しなければ、
以下のいずれかになるはずです。

実行順        eax   ecx
1, 2, 3, 4     1     1
1, 3, 2, 4     0     1
1, 3, 4, 2     0     1
3, 1, 2, 4     0     1
3, 1, 4, 2     0     1
3, 4, 1, 2     0     0

この結果からは、 eax = 1, ecx = 0 となるパターンはありません。
しかし、現実には、
  1 と 2 が逆転して、 2, 3, 4, 1 の順で実行される
  3 と 4 が逆転して、 1, 4, 3, 2 の順で実行される
などといったことが発生し、eax = 1, ecx = 0 となることもあります。

# 細かいことを言えば、現行の x86 CPU (x64含む) の中には、
# 1と2が逆転する (異なるアドレスに対する書き込み順が入れ替わる)
# ものはなかったと思うけど。あくまで「今は」であって、将来にわたて
# 保証されるものではありませんが。

でも、それじゃ困る場面が出てくることがあります。そのため、
順序保証をするためにメモリバリアという命令があるわけです。
今回の場合、以下のようにすると、1→2、3→4の順序が保証されるので、
eax = 1, ecx = 0 となるパターンがなくなります。

スレッド1
1: mov [x], 1
   mfence
2: mov [y], 1

スレッド2
3: mov eax, [y]
   mfence
4: mov ecx, [x]

※ メモリフェンス命令は mfence だけでなく、lfence や sfence
   というものもあります。あと lock プレフィクス使う手も。詳細は割愛。

# メモリアクセスの命令だけじゃなくて、他の命令も、いくつかの命令を
# まとめて実行したり (スーパースカラー)
# 順序を入れかえて実行したり (アウトオブオーダー)
# してるんだよね。
# 他の命令はその CPU 内部で完結するから実害ないだけで。


で、アセンブリで書かないとメモリフェンスを狙った位置に入れることは
できないのか、といえばそうではなくて、VC2005以降の volatile で
限定的とはいえ保証されていたり (このスレで既出)、その他、
処理系固有の拡張でメモリフェンスを適切に挿入できるようになっていたりしています。
C11、C++11以降だと、メモリモデルやマルチスレッドについての規定も
加わったので、標準の範囲で対策できるようにもなってきたり。

引用返信 編集キー/
■75481 / inTopicNo.9)  Re[6]: マルチスレッドのデータ競合
□投稿者/ yoh2 (9回)-(2015/03/28(Sat) 16:11:17)
ちょいと補足。

投稿中、「メモリフェンス」と「メモリバリア」が混在してしまいましたけど、
どちらも同じ意味で使っています。
普段「メモリバリア」で統一しているんですが、mfence という命令に引き摺られました (- -;

あと、文脈で判断できると思いますけど、eax, ecx の値とは、
性格には、スレッド2の実行コンテキストにおける eax, ecxの値のことです。

# 編集キー入力サボったらこれだよ……
引用返信 編集キー/
■75486 / inTopicNo.10)  Re[7]: マルチスレッドのデータ競合
□投稿者/ hikaru (4回)-(2015/03/30(Mon) 06:09:54)
774RR さん

どうも、ニュアンスを変えての事でしたが大幅に変更して頂いてありがとうございます。
アセンブラでの記述表現で直感的に捉えやすく、さらに理解が深まりました。

CPU 内部動作に付きましては、774RR さんの御回答が私自身の頭の中のもやもやを解消するとても
良い内容でしたので、目的が一緒に達成されたと言う事で解決でOKです。
--------------------------------------------------------------------------
yoh2 さん

どうも、詳細な説明をありがとうございます。

> メモリフェンスを適切に使わなければ、ゴリゴリアセンブラで書いても
> CPU が勝手に行う並べ替えを防げませんので不十分です。
mfence という命令を適切に挟めばアセンブラで書いても順序を抑制する事ができる。なるほど。

ちょっと簡単に調べて見たのですがハッキリしなかったので mfence 命令はアセンブラの命令?
それとも CPU 内部の特殊な命令なのでしょうか?

ふと思ったのだが、メモリバリヤの仕組みだけに着目していて、肝心な事に気づいていなかった。
私は、メモリバリヤを意識してプログラムを書いた事がないので分からないのですが、プログラムを組んで
いる最中に、ここのプログラムはメモリバリアで順序を抑制しないと変数値または意図した動作がおかしく
なるといった "ちょっとここやばいんじゃねぇ" と言うようなプログラムから見て感覚的に分かるようになる
ものなのでしょうか?
--------------------------------------------------------------------------
※余談です。
VCもバージョンが更新されるにつれてマルチスレッド関連のサポートを充実している見たいですが
メモリバリヤとか、こちら側で意識するのではなくシステム側でやってもらいたいものです。
DX11も本格的にマルチスレッドを意識したスレッドセーフ設計が行われ始めています。
今後両方に期待したいものです。

え〜とこれは、どちらの方にお願いしたら良いのかな。
メモリバリアについて詳しく教えて下さった yoh2 さんになるのでしょうか?

教えて貰ってる立場なのに何か指名するのは失礼なので
御回答頂けるならどちらの方でも結構ですのでよろしくお願いします。
引用返信 編集キー/
■75488 / inTopicNo.11)  Re[8]: マルチスレッドのデータ競合
□投稿者/ 774RR (250回)-(2015/03/30(Mon) 06:55:43)
sfence は SSE 拡張命令
mfence / lfence は SSE2 拡張命令

> メモリバリヤとか、こちら側で意識するのではなくシステム側でやってもらいたいものです。
今サポートされている以上のことは、たぶん絶対にやらないと思う。

今の時点で CPU core に比してメインメモリの速度は約2桁遅い。
スレッド間で同期を取るには L1 cache でなくメインメモリに値の書き込みを届ける必要があり、
そうすると CPU は100クロック近く/以上、停止することになる。
(mfence の実行クロックは約130クロック)

同期を取る必要が無いところで毎回こんなことをしていては性能が出ないし
「ここは同期を取る必要があるのか無いのか」は、コンパイラは自動では判断できない。
特に x86 はキャッシュ制御が良くできているので
・複数の変数間での「読み書き順序」までの同期が必要
な場合以外はほぼ何もしなくても同期が半自動で取れる構造になっている。
なのでコンパイラ側で「同期を取る」コードを勝手に生成することはまず無いだろう。
その必要があるところは「プログラマが意識して記述する」必要がある。

> 感覚的に分かるようになるものなのでしょうか?
知識と経験
今回このスレッドを立てたことで知識と経験が増しているわけだ。あとは
・ CPU のマニュアルを熟読するとか
・MSDN を熟読するとか
・同期に関して記述している文書や blog を読むとか
すると、たとえば InterlockedIncrement なんて関数がなぜ存在するかの裏がわかるようになる。

とりあえず x86 では (他のマルチコア CPU / SMP 構成機器は知らん)

スレッド間で共有する変数があるとき
・片方スレッドでは書くだけ、片方スレッドでは読むだけ、なら atomic アクセスをするだけ
・両スレッドで読み書きするなら同期が必要。
 ・その変数が1個だけなら「明示的同期」はまず必要ない
 ・複数の変数が同期しないとならないなら「明示的同期」が必須
くらいの理解でいいんぢゃないかな。
引用返信 編集キー/
■75506 / inTopicNo.12)  Re[9]: マルチスレッドのデータ競合
□投稿者/ yoh2 (10回)-(2015/04/01(Wed) 01:36:14)
私も 774RR さんの意見に同意。
ちょっと補足するなら、「明示的同期」という奴も、ロックフリー
アルゴリズムを書くのでもない限り、アウトオブオーダだ
メモリバリアだと面倒なことを考えずに、OSやライブラリで
提供されているロック系のAPIを使えばいいです。

Win32 なら EnterCriticalSection() と LeaveCriticalSection() の組、
pthread なら pthread_mutex_lock() と pthread_mutex_unlock() の組だとか。
それらの API 呼び出しを超えて順序がおかしなことにはならないことが保証されてます。
# 内部的には、大抵、API実装の中でメモリバリア使ってるわけですが……

それじゃ遅すぎる、となった場合も、まずは設計や、
(上記APIが使える範囲で)アルゴリズムを見直して、それでも
ダメとなったら初めてロックフリーアルゴリズムに手を出す、
くらいでよいのではないかと。
引用返信 編集キー/
■75508 / inTopicNo.13)  Re[10]: マルチスレッドのデータ競合
□投稿者/ 774RR (251回)-(2015/04/01(Wed) 07:01:04)
そしてちゃぶ台をひっくり返してしまうわけだけど

ソフト修正に手を付けるのはマルチスレッド化したほうが良い(性能が改善される確信がある)と判断した後でよい。
今はターボブーストとかあるわけだし。

下手なプログラマによる「ソースコードの改善」より、よっぽど
その専門家が熟考して作った「ツール(コンパイラ・ハードウエア)による改善」のほうが結果が期待できたりする。

いまどき VC++6 なんでしょ?
素直に VS2013 あたりに更新するといいんではないかな・・・

いまどき Windows 98SE なんでしょ?
End of Life に達してサポートも打ち切られた OS を使い続けるより Win8.1 に更新するほうがいいんではないかな。
# といいつつウチも Win 7 なんだけどさ

いまどき Win98SE が主流だったころのマシンをまだ使ってるの? Pentium 3 あたりなのかしら?
Core i7 4桁台に(親父んちのマシンを)更新したら感動的速さだったけど。

ちゃんと動作しているソフトは触るな。なんてことわざ?もある。
投資するなら最も効率の良いところにするべし。

引用返信 編集キー/
■75510 / inTopicNo.14)  Re[11]: マルチスレッドのデータ競合
□投稿者/ hikaru (5回)-(2015/04/01(Wed) 13:48:49)
774RR さん

> 知識と経験
ズバリ仰る通り、今私に特に経験が必要ですね。

マルチスレッド関連のサイトで集めた沢山の知識と、ここで得た貴重な知識は私の頭の中から引き出せる
力を豊富にしたと思います。
後は、沢山のプログラムを組んでそこから得られる経験値を学びたいと思います。

※また余談です。
低スペック環境( 幾らなんでも古すぎるだろうとツッコミが飛んできそうですが )で開発するのは、私自身の
勝手な持論がありまして、最新の OS にすと快適に作動させる為にそれなりのパソコンのスペックが自動的
に必要です。

高スペック環境で開発 :
ヘタなプログラムを組んでも高速に実行できる。
リファクタリングを作業をサボる。

低スペック環境で開発 :
リファクタリング作業が必要。
プログラミングの力が身につく。

この様な上の理由からあえて古い環境で作業を行っています。

私の現在の希望 :
OS は XP ぐらいで、開発環境は VC2005 ぐらいの搭載できるパソコンが今の私にはちょうどいいかな。
コア数は、真のスレッドの同時動作を確認したいので最低 2 個以上は必要かな。
-----------------------------------------------------------------------------
yoh2 さん

> それじゃ遅すぎる、となった場合も、まずは設計や、
> (上記APIが使える範囲で)アルゴリズムを見直して、それでも
> ダメとなったら初めてロックフリーアルゴリズムに手を出す、
> くらいでよいのではないかと。
マルチスレッドのプログラム上で、ここはロックフリーアルゴリズムにするのか明示的ロックにするのか
の使用所を見極める力、これは経験上からしか養われないと思いますので今はやっぱり経験値を増や
す事が近道ですね。
-----------------------------------------------------------------------------
どうも、774RR さん と yoh2 さん には大変お世話になりそして、とても良い勉強になりました。
どうもありがとうございました。
解決済み
引用返信 編集キー/
■75512 / inTopicNo.15)  Re[12]: マルチスレッドのデータ競合
□投稿者/ なちゃ (29回)-(2015/04/01(Wed) 14:29:57)
No75510 (hikaru さん) に返信
> 高スペック環境で開発 :
> ヘタなプログラムを組んでも高速に実行できる。
> リファクタリングを作業をサボる。
>
> 低スペック環境で開発 :
> リファクタリング作業が必要。
> プログラミングの力が身につく。
>
> この様な上の理由からあえて古い環境で作業を行っています。

んーこういう面は確かにあったりもしますが、逆の問題も結構あって、あまり古すぎるとむしろ弊害ばかりになりそうな気がします。
まあご自分でも書かれてますが、マルチコアすら使えない環境では全くまともな検証もパフォーマンスの確認も出来ないですし。
それに、環境が変わると常識も結構変わるというか、バッドノウハウが通用しなくなったり、害になったりもするので、正直おすすめできません。
環境が古いのではなく、スペックが低い環境で動作確認する、てんなら分かるんですが。
解決済み
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -