並列プログラミングの方針
はじめに
ここに書いていることは、あくまで僕の理解であって、参考にした資料のそれとは異なるかもしれません。鵜呑みにせず、資料をよく読まれることをおすすめします。
とっかかり
Concurrency - Radium Software Developmentが興味深い。並列プログラミングでSingletonを扱う場合で、パフォーマンスを上げようとしているのに、ロックによってパフォーマンスが落ちてしまう、それを防ぐためにDouble-Checked Lockingというパターンを使うが、このパターンには穴がある、という話。
dW double-checked lockingとSingletonパターンには、その問題に対する解決策が二つあげられている*1。
また、参考資料の一つにLarry Osterman's WebLogがあり、その中の並列プログラミングの5つの方針があったので、読んでみた。
5つの方針
I next introduced my principles of concurrent programming:
1: If your data is never accessed on more than one thread, then you don't have to worry about concurrency.
2: Critical sections can be your best friends (unless they're your worst enemy).
3: Know your lock order and never, ever violate it.
4: Don't call into other objects with locks being held, and make sure that you reference count all your objects.
5: Reference counting is hard if you're not really careful
5つの方針（和訳気味）
- 複数のスレッドからのアクセスが一度もないデータについて、並列性を心配しなくてもいい。
- クリティカルセクションは最高の相棒になるかもしれない（それらが最悪の敵にならない限り）。
- ロックの順番を知り、順番を決して間違えないこと。
- ロックを保持した状態で他のオブジェクトの呼び出しを行わないこと、全てのオブジェクトへの参照数を確認すること。
- 本当に注意深くやらないと、参照カウントをとることは大変だ。
方針に関する考察
このうち、4、5については実感が湧かない。
1。問題ない。
2。クリティカルセクションは、同期を取るための手段として有効だが、使い方によってはデッドロックを招く可能性がある。3に少し掛かっている。
3。ロックする順番を統一しておかないと、デッドロックが起こりうることについての示唆。
スレッドプログラミングについては、Javaや.NETなどスレッドを考えられて作られた言語での解説が多い気がする。Larry OstermanはWindowsでの例を挙げている。
*1:根本的な解決策ではないようだ
