[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/ )