[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 12615] Re: 2007/2/17 議事録 [ 改 ]



  高橋(智)@世話人です。
  議事録の体裁を整えて、Webサイトに掲載いたしました。

----------------------------------------------------------------------------------------------
Java読書会 2007/2/17 議事録
吉本 大石 小松 小棚木 岩室 村山 遠藤 高橋 鈴木 高橋 根本(記)

P311より
13 明示的なロック
 ポーリングによる入手
 時間制限付き
 インタラプトで入手

ReentrantLockは必ずfinallyで開放をすること、synchronized method より危険

Javaのfinallyつにいて
C++のdestructor はblockを出るときにlocal変数をdestructorが自動で開放する。のでC++は書き忘れはない。
抜けるときに勝手にunlockする。
C#はdisposableがある。C#ではlockはcompilerが勝手にやってくれる。
lock /unlock のネスト交差させる書き方の要求があれば、unlockが自動開放でないことも好意的に解釈できる。
ReentrantLock は lockしたownerが記録されて、自分がオーナであることがわかる。
ReentrantLockは 自分のlockした中身に再度進入できる。
semaphoreにはownerの考えがないので、誰が開放してもよい。

13-1-1 ポーリングによる入手と時間制限付きの入手
 "back off" とは? ←不明な専門用語
 debit() 引き出し
 credit() 入金
 accountオブジェクトにtransferメソッドを最初から持たせるべきか?
 トランザクションロジックは外出しのほうがいいはず、しかしlockメソッドがpublicなのは不安。
JDK7でのSuper Package = 公開対象パッケージが指定可能、publicの一段下の制限  表記法は宿題
long nanosToLock = unit.toNanos(timeout) の表記方法は、お約束パターン

13-1-2 インタラプトできるロックの入手

13-1-3 コードブロックにとらわれないロック
連結リストに対して、"hand-over-hand locking" or "lock couping" ロックを次々手繰り寄せる方法。
可変長操作の時に有効。その連結の両端のみをつかんでいればよい。
DCAS (Double compare-and-swap) のCPUがあれば、lock free な操作が可能だかDCASは存在しない。

13-2 実行性能への配慮
hotspotが最適化したコードはdumpして見るしか手段がない。 binary hack しかない。
(postgreSQLはvacuumとanalyzeは、必ずかけよう)

13-3 公平性(fairness)
公平性を操作するoptionはないのか?
軽量言語の場合はプロセス間通信のほぁ &$,IaDL

13-4 synchronizedとReentrantLockの使い分け

13-5 リードライトロック
Javaの場合はすべてのobjectが組み込みlockを持っているのでトレースしやすい。
java.lang.Objectがwait() notify(), notifyAll()をfinalで持っている
java.util.concurrent では await() signal() signalAll() で衝突を避けている。
JConsoleでアクセスするとdeadlockの検知ができる、しかしReentrantLockの検出は難しい。

14 カスタムシンクロナイザを構築する

14-1 ステート依存を管理する

14-1-1   GrumpyBoundedBuffer  (Grumpy=気難しい)  七人の小人から・・・
ちなみに七人の小人は・・・  Doc  Grumpy  Happy  Sleepy  Bashful  Dopey  Sneezy

14-1-2 ポーリングと休眠による荒削りなブロッキング

14-1-3 条件キューが助けてくれる
Object.wait() にタイムアウトは設定可能、waitの引数でセットできぁk!#!!!!timeoutすると、処理が続行するだけ、
timeoutの結果は視h$l$J$$!!!!notfifyAll()は引数なしなので、呼ばれたからといって自分の条件が成立したとはいえない。

14-2 条件キューの使い方

14-2-2 早すぎるウェイト終了

14-2-3 シグナル消失

14-2-4 通知
List14-8の実装は、本当に空のときしか通知しないので、使うのはちょっと怖い。
表記上notify()とnotifyAll()ではnotify()がデフォルトに見えるが間違い、notifyAll()をまず使うべき。

14-2-5 ゲートクラス

14-2-6 サブクラスの安全性の問題

14-2-7 条件キューをカプセル化する

14-2-8 入り口と出口のプロトコル

14-3 明示的な条件オブジェクト
wait() - await()、notify() - signal()、notifyAll() - signalAll() という対比で Conditionインターフェイスを使用する。
Objectクラスの方のメソッドはpublic finalなので  隠せない、@Deprecated なら使えるのではないか?

14-5 AbstactQueuedSynchronizer
java.util.concurrent.Lockに AbstactQueuedSynchronizerがある。

14-5-1 簡単なラッチ

14-6 java.util.co!ncurrentのシンクロナイザの中のAQS

14-6-1 ReentrantLock

15 アトミック変数とノンブロッキング同期化
compare-and-swap はアセンブラレベルでのatomic操作

15-1 ロックの不利な点
Adaptive lockを実行する、お利口なJVMとは誰か?

次回(p359) 15-2 ハードウェアの並行性サポート から
----------------------------------------------------------------------------------------------


-- 
高橋智宏
  Java読書会( http://www.javareading.com/bof/ )