TMK

WindowsMobile5は言うこと聞かないね

目次

Blog 利用状況

ニュース

参加コミュニティ

書庫

日記カテゴリ

クオリティ

こんにちは。ddnpです。
ソフトウェアの品質について、思ったことを少し。

例えばスレッド切って何かやる、というときに
その制御として、グローバル変数を中断フラグに用いて・・・なんていう
へっぽこソースが、現に商用環境で動いているとします。

で、それを書いた人に意図を問うと、「これで十分だから」なんていう
回答が来たりする。
「volatileじゃないと、あぶないんだよ」なんて。ハイ。わかりました。

木工大工で、釘の先端が突き出たまんまじゃ危ない、だからその先端は削り落としました。
それもいいでしょう。
しかしよりベターなのは、釘を使わずに組むこと。
これにより完成品の見た目もよくなるし、釘の先端を削るような労力もいらない。

前の例では、スレッド使うなら同時に制御用のカーネルオブジェクト、
知らないなら勉強しましょう、実験して身に付けましょう。

品質はそうやって上げていくんじゃないのかな。

投稿日時 : 2007年6月8日 10:59

コメントを追加

# re: クオリティ 2007/06/08 11:11 シャノン

WaitForSingleObjectは、どうしても「待つ」というイメージがあるので、待ち時間に0を指定して「調べる」という使い方は、何度か見ているのに思いつかない。
精進が足りないなぁ。

# re: クオリティ 2007/06/08 11:51 とっちゃん

マルチコアな環境で、実際にダメパターンを見せてあげればw
うちは、早くから(おいらが要望してw)DualCPU使ってたんで
マルチスレッド絡みの同期処理はみんな泣かされてますよ<やってる人w

マルチスレッドでのよくわからん不具合は一通り経験してますw

# re: クオリティ 2007/06/08 13:06 シャノン

マルチスレッドプログラミングってのも、Deep Sessionにはいいネタかもしれないね。

# re: クオリティ 2007/06/08 13:50 ddnp

マルチコアああ
マルチプロセッサあー シャッチョさんオカネモチー(違

しかしプログラムは変わらないですよね?
(あれ、ちがう?w)
"並行"を意識してスレッド切るとか、そんな感じかしら

# re: クオリティ 2007/06/08 14:59 とっちゃん

真の同時実行がなされますよ<マルチコアな環境のマルチスレッド
似非じゃなくなるので、本当に同時アクセスするw

こういう環境でつくると、どのくらい同期せずに動かせるかとか
どのタイミングでスレッドが同期していないといけないかとかを
明確に意識しますw

メモリアクセスまで含めてねw

>Deep Sessionにはいいネタ
いえてるな。こっち方面も考えてみるかなww
でもその前にメモリ管理をおさえて置かないといけない気がする...w

# re: クオリティ 2007/06/08 16:46 ddnp

むむむ。MSDNに記述があった。
http://msdn2.microsoft.com/en-us/library/ms686355.aspx

::Interlocked~系も、64bitの環境では問題がある(ていうかだめ)というし、
こりゃ情報収集からやり直し。

# re: クオリティ 2007/06/08 16:55 とっちゃん

>64bitの環境では
えーそうなの?64bit環境はいまのところほぼ放置だからなぁ...
Interlocked はInc/Dec しか使ってないとおもうけど...大丈夫かな?

# re: クオリティ 2007/06/08 17:54 シャノン

Interlocked API は、そのまんま、CPU のネイティブな Increment / Decrement / etc... 命令を呼んでるだけだそうで。
そのあたりに起因するのかしら?
まさか x64 CPU には 32bit のアトミックな加算命令が無いなんてことは無いと思うけど…

# re: クオリティ 2007/06/08 21:56 なちゃ

んー使い方が間違っててそもそも正しく動作しないコードになってるとか、
グローバル変数でフラグ使いまくりとか、そういうのは論外として、
終了要求フラグのようなものでカーネルオブジェクト使用すると、たとえばどんなメリットがあるんでしょう?

# re: クオリティ 2007/06/08 22:02 なちゃ

実は中途半端にマルチスレッドを意識しているプログラムが厄介だったりしますね。
※ちゃんと考えているようで、ちゃんとは考えてないことがもう…

# re: クオリティ 2007/06/09 8:17 ddnp

>終了要求フラグのようなものでカーネルオブジェクト使用すると、たとえばどんなメリットがあるんでしょう?
人間側の視点でいうと、まず目的が明確になりますよね。
プログラムの見通しがよくなって、メンテナンスに有利。

次にコンピュータ側の視点では、リソースの消費を抑えることができます。
今回の例では、サブスレッドが自分自身の仕事を続けてよいかお伺いする場合、
結局は何らかの値を見張らなくてはいけないのですが
プロセスがそれを行うんじゃなくて処理系に任す。
先頭でシャノンさんが言っている::WaitFor~の目的はそれです。

で、大きなプログラムになってくると、スレッドの終了要求だけでなく
ウィンドウメッセージとか他のイベント・ミューテックスなども
同時に見張る必要が出てくる(かもしれません

そんなときは ::WaitForMultipleObejct()であるとか
::MsgWaitForMultipleObjects()などを使っていかないとイケナイ。

#ほら、グローバル変数の出番なんてなくなっちゃった^^

# re: クオリティ 2007/06/09 10:39 なちゃ

すいません、そういう意味ではなくて、うーん、ちょっと限定された状況について書きすぎましたかね…

適材適所で同期オブジェクトをうまく利用するのはもちろんとして、同期オブジェクト以外で何かを管理
イコール
即駄目駄目って雰囲気だったので、単に場合によること「も」あるのでは?といいたかっただけです。

ループで終了フラグを監視するとか、さすがにそういうことを言ってるわけではないです。
タイムアウト0の同期オブジェクト待ちとフラグチェックで、そこまで極端に差があるか(品質の悪いへっぽこと言われるほど)、て程度の話です。

※後々のことを考えて同期オブジェクトにしておくとか、そういうのも別に否定するわけではないんですが。

# re: クオリティ 2007/06/09 11:40 中博俊

今設計しているシステムでもWaitForはつかってません。
Pollingの嵐です。
WaitForできるのはまさしくWaitForできる局面に限られるので、WaitForできない物に対しては有効ではないからです。
#当たり前のことをもっともらしく書いてみました(^^;;

# re: クオリティ 2007/06/09 12:49 ddnp

表現の悪いところがあったかもしれない。

状況に応じて『選ぶ』のが肝心。
で、『選ぶ』ためには手段をいろいろ知ってないといけない。

木を接合するのに釘を打つしか知らない人と、
ほかの手段(ボンドでもダボでも)を知ってる人とでは、
(状況に応じて手段を選べる分だけ)仕上がりに差がありまっせ。ということ。

だから色んなことを考慮して
結果グローバル変数でよければそれでいいだろうし、
他の制御がいるなら、それに応じた手段を取らないと(取れないと)いかんよね、、、
という話。

# すべからく同期オブジェクトを云々、といった話ではない

タイトル
名前
URL
コメント