排他制御の機能でタスク間の待ち合わせを行うのがいかにCPUパワーを無駄にするかをダラダラと書いているわけですが、何が書きたかったのかだんだんわからなくなってきました。
とりあえず同期について書いてみたいと思います。
タスクAとタスクBが協調して動作するためには同期機構は必須であると主張しているのを見かけました。
つまりこういうことです。
タスクAのタスクを分割すると、A1,A2,A3。タスクBはB1,B2。処理の順序に制約があるため、A1,B1,A2,B2,A3と実行しなければなりません。
そこで、両者の間にセマフォS1,S2を用意して同期を取ることにしました。最新メジャーな超高性能OSを用いているため、オーバーヘッドはごくわずかです。
そこで素朴な人はこういうわけです。
タスクAとタスクBは同じタスクじゃだめなんですか？
タスクA,Bを合体させてC1,C2,C3,C4,C5という処理の流れにしたら、何か問題があるのですか？
すると、実はタスクBの兄弟タスクDがあって、これはタスクD1,D2,D3となっていて、D1がB1にD2,D3がB2に対応するから、タスクAと協調するときには、A1,D1,A2,D2,D3,A3と処理しなければならないなどと言い出すわけです。歴史的経緯を辿ればすぐにわかることですが、タスクDは後付で追加されこのときにタスクAからタスクBが生み出されたというわけです。よくある風景のようです。
ですが、タスクBとタスクDをifやswitchで場合分けするとモジュールが大きくなりすぎるからそれを分割するというのは良いことだと思いますが、タスクに分割する必要性は全く無いのです。こういう場合は。
このようにシステムプログラマーさんが語る、排他制御や同期機構の問題以前の問題が現場では多くを占めているような気がします。たぶん、根本的にタスクが何かを分かっていない人たちがアーキテクトを務めたらこうなるのが必然なのでしょう。
そしてひとつひとつ指摘していくと、すぐにシビレを切らせて怒り出す技術者が大変多いです。「ウチのシステムはそんなに単純なつくりじゃない！もっとフクザツで大規模なんだ！」と。
フクザツで大規模なのは、政治学が正しく機能していないからでしょう。製品として重要な部分に強い権限が与えられず、本筋とは関係ないのにバグばっかり作りこんで炎上している部分にばかり開発リソースとメモリとCPUパワーが与えられているだけのことで。
しかも炎上している部分の担当役員ほど、多くの予算を動かしているわけで、盗人猛々しいとはこのことかもしれません。もちろん外注さんも炎上すればするほど売り上げアップですしネ！
絡んだ毛糸玉をほどくには、目に見える糸を切って取り出して結びなおすほうが速いと思うのは私だけでしょうか。もちろんリグレッションテストの環境が整備されていなければ、何もできません。当たり前です。
コメント