上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

勘違いから変な事を思い悩んだのでメモ…。

マルチスレッド化可能なクラスを作ってて、内部で使ってる同期の仕組をクライアントに公開し…クライアントと同期の連携を取る。…という事を考えた。で、それにはLockを公開すればいいのか、synchronized用のモニタを公開すればいいのか?…どっちなん?と。

で、もうたぶん、スタートがおかしいんだけど…泣…そこから…以下の様に発想…。

  1. Collections.synchronizedCollection(c)はthisのモニタで連携を取れと書いてる…?
  2. でも、そんなのはクライアント側の好みや都合があるから、好きな方を選べるようにすべき。
  3. synchronizedかLockか選べるようにするには…意外難しい…?
  4. ロックの取得と解放から本体処理への流れをメソッド化…??
  5. で、それを…
    • オーバライド出来るようにする…???
    • コンストラクタで指定したフラグでロックの方針を切り替える…???
  6. どっちも激しく変!

結局、まず間違いは、内部で使う不変条件を保つための同期と外部で使う複数のメソッド呼び出しを繋ぐための同期を連携という名の元に混ぜてしまった事。こいつらは確かに混ぜる事は出来るけど、出来るからといってすべきじゃない。分けた方が各同期用オブジェクトの意味がはるかに分かり易くなる。分けるとだいたいこんな感じになる。

内部
その場に適した同期方式を使う。Lockにしろモニタにしろ、protected又はprivateにし、外に公開しない。
外部
同期ラッパーと手動の同期方式を組み合わせる。大事なのはその両方で同じ同期方式を使う事だけ。Collections.synchronizedCollection(c)ではモニタを使う方針だけど、気に入らなければLockを使うラッパーとそれを使った手動の同期でも構わない。

使用に当たっては、外部の対策だけでもオールラウンダーになれる。逆に内部の対策だけでは無理なのでラップが必要。ただ、内部のみの場合、ロック時間が短いのでその分優位。で、結局、大事なのは、内部でも外部でもLockだろうがsynchronized用のモニタだろうが、お好みの同期方式を使えたって事…。

うーん、微妙な解釈の違いが蓄積して最後は意味不明に…か。例えるなら、仕様書の森での遭難…かな。…ん?…全然うまく言えてない?……もう寝よう…はぁぁ…。

役に立ったらぽちっとよろしく。 人気ブログランキングへ


ちなみに、この考え方だと、VectorやHashTable等の古い(Lock等が登場以前の)APIは今となっては若干設計がまずい事になる。これらは同期機構が最初から組み込まれてて確かthisによる同期を使ってる。そして、それは内部の同期機構をprotectedかprivateにする…という原則から外れる事になる。

スポンサーサイト
コメント
この記事へのコメント
コメントを投稿する

トラックバック
この記事のトラックバックURL
この記事へのトラックバック
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。