共有メモリについて – 固定ページ 2 – プログラミング – Home

通知
すべてクリア

共有メモリについて

固定ページ 2 / 2

ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

今までの話を聞いていると、次の方法はだめですか。

1. 共有メモリーと別に共有の書込みフラグ作る。
2. ひとつのスレッドが書込むたびにフラグを立てる。
3. 書込み終了時にフラグを解除する。
4. 他のスレッドはフラグを見て、立っていたらエラーで他の作業に移る。
  #そのときミューテクス等をつかうのかな?

以上では、不十分ですか?


返信引用
επιστημη
 επιστημη
(@επιστημη)
ゲスト
結合: 22年前
投稿: 1301
 

> 1. 共有メモリーと別に共有の書込みフラグ作る。
> 2. ひとつのスレッドが書込むたびにフラグを立てる。
> 3. 書込み終了時にフラグを解除する。
> 4. 他のスレッドはフラグを見て、立っていたらエラーで他の作業に移る。

これだと誰かが読んでる最中に書き込めてしまうのでは?


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

>これだと誰かが読んでる最中に書き込めてしまうのでは?
そうですよね、失礼しました。
でも、フラグで強化すればうまくいきそうなきがするのですが。
確かに、DLLの場合どんなスレッドがアクセスしてくるか
分らないので、難しいですね。


返信引用
Ban
 Ban
(@ban)
Prominent Member
結合: 5年前
投稿: 776
 

> ITO さん

適当にぐぐってみました。ちゃんと中を見てなくて済みませんが、参考にはなるかと。
http://anoncvs.internet2.edu/cgi-bin/viewcvs.cgi/shibboleth/c/shib/shib-threads-
win32.cpp?rev=1.3

# POSIX では pthread_rwlock なので、rwlock という名前の実装も多いです。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

Banさん
有難うございます。
参考になりました。

「readers-writer-lock」を僕もぐぐってみましたが、
件数が多くて絞込みきれませんでした。

ミューテクスを使用して、イベントで受けて、クリティカルセクション内で
読込みと書込みのフラグをチェックしているのですね。
マルチスレッドで互いに読み書きする環境だと排他制御も複雑になるのですね。


返信引用
Ban
 Ban
(@ban)
Prominent Member
結合: 5年前
投稿: 776
 

> マルチスレッドで互いに読み書きする環境だと排他制御も複雑になるのですね。

全部のアクセスを排他制てしまう(たぶん↓)のが、必要最低限の、最もンプルな方法だと思います。
> #共有するときは、お互いにかち合わないように考えているので。

その上で、「アクセスを効率化した排他制御」とか考え出すと、
rwlock の方が効率がよくなる可能性があがります。
# 実際には、規模や読み書きの比率次第で、速度は大差なかったり、逆にシンプルに排他した方が
# マシだったりとかしますので、要プロファイリングですが。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

僕の会社では、一人でひとつのソフトを担当するので、
 「共有するときは、お互いにかち合わないように考える。」
 のは意外とすんなりいくことが多いです。
しかし、普通数人で一つのソフトを仕上げるみたいですから、それを考えると
「排他制御」が重要視されるのかなと思います。
今回の件、考えてみればアプリケーション側に共有メモリーを持たせてDLL側は、
そのメモリーを参照する方式をとれば、「排他制御」も複雑でなくなるかも
知れませんね。
僕が、DLLを作るときは、共有メモリとしてDLLにヘッダーファイル中に
定義して、あくまでもアプリケーション上で使うようにしています。
そうすれば、共有メモリもアプリケーションで管理できますから...........


返信引用
Ban
 Ban
(@ban)
Prominent Member
結合: 5年前
投稿: 776
 

> 僕の会社では、一人でひとつのソフトを担当するので、
  -- snip --
> 「排他制御」が重要視されるのかなと思います。

単に ITO さんの会社では、一人が単一プロセス/スレッドで組んでいるから、
担当レベルで排他すれば動くということかと。

排他制御の必要性は主にプロセス/スレッド構成に起因していて、
一般的には一人で書いてるマルチプロセス/スレッドもよくありますし、
作業人員が何人であろうが、実行単位が複数ある限り、排他制御は重要です。
# 作業人員の話はたぶん、「打ち合わせしないで仕様を決められるか否か」の違いですね。

> 今回の件、考えてみればアプリケーション側に共有メモリーを持たせてDLL側は、
 -- snip --
> そうすれば、共有メモリもアプリケーションで管理できますから

根本的に、「共有メモリ」を他のアプリと共有するのであれば、アプリ側に持って参照しても
簡単にはならないです。大抵の場合、アプリ側に個別の参照ルールを強要することになるので、
おそらくより複雑になると思います。

ITO さんの会社のように?、単一プロセスのアプリで完結していて、共有メモリをアプリ間で
共有しないという前提があるならば、どちらにおいても大差ないでしょうし、
アプリ側にあった方が楽かも知れません。
但し、それは既に前提条件が変わっていますし、共有メモリである必要性があるのか疑問が残るかも
しれません。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

 ソフトの規模が大きくなると一つのアプリでは収まりきれなく、複数のアプリ
で構成されるということですね。
 複数のアプリで構成するソフト開発では、複数のプロセス間での通信になり、
そのための共有メモリが必要になるのですね。

Banさん
丁寧に有難う御座いました。


返信引用
固定ページ 2 / 2

返信する

投稿者名

投稿者メールアドレス

タイトル *

プレビュー 0リビジョン 保存しました
共有:
タイトルとURLをコピーしました