- - PR -
SharedMemoryの排他制御について
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-03-22 13:22
>Mutext(FALSE,"MyMutex") や OpenExisting("MyMutex") が
>何しているのか分かりませんが、チェックなどしなくても、 >名前付き Mutex を作る際にまだ Mumtex が存在しなければ作るし、 >既に存在すれば作成済みの Mutex のハンドルを返しますよね。 はい。 説明が悪くて聞きたい事が伝えられていないかもしれないので、再度。 私が気にしているのは・・・ DLL内でMutexを使って排他制御しようとした場合、そもそもプロセスとして別々のexeからDLLが呼出されてしまっては、Mutexの意味が無くなってしまう。(名前付きMutexは別々のプロセスでは唯一になれない) と、言った(私の知らない)仕様があるのか?と、言う事です。 DLLはexeのメモリ空間にLoadされてしまうから、プロセスが別々になれば同じ名前のMutexも又、別々になってしまう。のか?と、心配した次第です。 私の勘違いならば良いのですが・・・ | ||||||||
|
投稿日時: 2007-03-22 13:32
なるほど。杞憂です。でなければわざわざ Mutex を使う必要ないですもんね。
_________________ 囚人のジレンマな日々 | ||||||||
|
投稿日時: 2007-03-22 13:41
>なるほど。杞憂です。でなければわざわざ Mutex を使う必要ないですもんね。
上記回答ありがとうございます。 安心しました。 結論としてDLL内でMutexを使って排他制御する事にします。 本当は呼出し側のexeで排他制御するスタイルが良いのですが・・ 既に大量のexeが出来上がってしまっていて、SharedMemory-DLLだけが遅れている現状、各exeに「Mutexを使って排他制御する機能を追加しろ」とは言えず・・・ 又、イケてないシステムを一つ増やしてしまいそうですが・・・ 以上、アドバイスくださった方々、ありがとうございます。 大変参考になりました。 | ||||||||
|
投稿日時: 2007-03-22 13:50
こんんちは
名前付きミューテックスはコンピュータで唯一のものになるはずです。 セマフォも同様です。 read/writeのそれぞれの処理中のみ排他制御をしても意味がない場合が多い気がします。 通常は読み込み〜加工〜書込みのセットになると思うのでread/writeのほかに lock/unlockのapiを追加して積極的な排他制御をした方がいいかと思いますが.. いかがなもんでしょ | ||||||||
|
投稿日時: 2007-03-22 14:10
0ではないとしても、実際にどれだけの大きさが利用可能かは分からないので、大規模な領域を必要とするなら、ユーザファイルを指定しておくのが無難と思います。
杞憂です。 ファイルマッピングを使用するプロセスが1つもなくなった時点で、ページファイル上に確保されたファイルマッピング用の領域は解放されて再利用されます。 とは言え、最初からOSによるクリーンナップをあてこんだコーディングというのもよろしくないので、適切なエラー処理を組み込んでください。 [ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2007-03-22 19:14 ] | ||||||||
|
投稿日時: 2007-03-22 14:11
システムとして整合性のとれたものになるか、心配。
ロックの仕様を確認し、本当にDLLだけでなんとかできるか、確認するべきかと _________________ | ||||||||
|
投稿日時: 2007-03-27 00:07
Mutex を使って排他制御する場合 WindowsXP 以降のOSでは、グローバルミューテックスを使うことをお忘れ無く。
Mutex の名前の前に Global\\ を入れないと、コンピュータで唯一の資源をアクセスするための排他はできません。 |