[jfriends-ml 10284] 同期化／同期処理

[Murayama Toshikiyo <murayama@xxxxxxxxxxxxx>]

(株)NETGENEの村山です．

> 最初の例でスレッドセーフにしたければ，プログラマーが自前で
> 同期処理を行うべきです．

> ＃ぶっちゃけた話，同期をMT-Safeなクラスや過剰な同期に頼るのは
> ＃二流プログラマーの証．

ひょっとして，マルチスレッドプログラミングの経験のある人と
ない人では，同期処理に対する意識が根本的に違うのかもしれ
ませんね．

例えば，
 1,(逐次で)プログラムを作る．
 2,その中でマルチスレッドで危険な個所を，「同期化」する．
 3,実際に動くかどうか確認する．
という意識で作っている人はいませんか？
＃いないというなら一安心．

マルチスレッドでは，むしろ，
 1,マルチスレッド用にアルゴリズムとデータ構造を設計する．
   (「同期処理」はアルゴリズムの一部．)
 2,それを実装する．
 3，実際に動かしてみて，実測値が理論値と合うか検証する．
という発想で作るべきですし，そうしないとまるでパフォーマンスが
出ない場合もあります．
＃それこそ最悪ではデッドロック．

マルチスレッドプログラミングでは，同期処理というのは
アルゴリズムの根幹を成すものであり，最初に設計すべき
部分です．セキュリティでもそうですが，後付けでどうこう
できるものじゃないと思います．
＃場合にもよるが「同期処理という骨組みに肉付けしていく」
＃という感じに近い．

もちろん，実際にはさほど高度な同期処理を必要としない場合も
多々あります．例えばホームページを動的に生成するくらいならば，
それほどのパフォーマンスも必要ないし，もともと同期処理も少ない
ために設計は容易でしょう．また，既に逐次で動いているプログラム
を移植するので，できる限り書き換える部分を少なくしたいという
場合もあるでしょう．

このような場合でも「高度な同期は不要である」，「どのような
同期がどこに必要か」，「その同期がボトルネックにはなる心配は
ない」などは，設計の初期段階で前もって確認しておく必要があります．

同期を気にせずにプログラムを作成していると，実際にパフォーマンス
が出ないと気づいた時には，既に手遅れという可能性も高くなります．
最悪の場合はアルゴリズムから実装まで，全て作り直さす羽目に
なることさえ考えられます．

たとえば，シングルトンで一意性を保証したインスタンスへ頻繁に
アクセスするような場合などはこれですね．逐次ならさして問題は
無いものの，マルチスレッド(というよりは並列処理)では致命的な
ボトルネックになることもあります．この場合はシングルトンを
使わない形にアルゴリズムから書き直すことになるでしょう．

＃こういう意識でプログラムを書いていると，MT-Safeなクラスや
＃モジュールなんて，バカバカしくてまず使う気にならないと思う．