Gc cr/current block 3-way

gc cr/current block3-wayイベントはgc cr/current requestイベントのFixed-upイベントで、ブロックを要求されたプロセスが、マスターノードではなく、第3のホルダーノードからブロック画像を転送受け取ったことを意味します。gc cr/current block3-way待機イベントは、ノード間の通信回数が多いという点を除けば、gc cr/current block2-way待機イベントとほぼ同じ意味を持ちます。gc cr/current requestイベントがgc cr/current block3-wayイベントに変わる（fixed upされている）の流れは、以下の通りです。

・リクエストノードのユーザプロセスが特定のデータブロックを読もうとします。
・ユーザプロセスは、データブロックの適切なバージョンがローカルバッファキャッシュにないことを確認し、
　マスターノードのLMSプロセスにブロック転送を要求します。ユーザプロセスは、応答を受信するまで、
　gc cr /current requestイベントを待機します。
・マスターノードのLMSプロセスは、GRDを介してそのブロックの最新のバージョンを第3のホルダーノードが
　保有していることを確認し、ブロック転送要求をホルダーノードに転送します。
・ホルダーノードのLMSプロセスは、自分のローカルバッファキャッシュに要求されたブロックの画像が存在する
　ことを確認して、インターコネクトを介してそのブロックの画像をリクエストノードに送信します。 
　CRブロックを送信する場合には、gc cr blocks served、gc cr block build time、gc cr block flush time、
　gc cr block send time統計値が増加します。 Currentブロックを送信する場合には、gc current blocks served、
　gc current block pin time、gc cr block flush time、gc cr block send time統計値が増加します。
・ユーザプロセスは、ブロック画像を送信されて、gc cr / current requestイベントをFixed-upイベント
　gc cr block 3-wayイベントやgc current block 3-wayイベントに変更する。 
　CRブロックを送信された場合には、gc cr blocks received、gc cr block receive time統計値が増加します。
  Currentブロックを送信された場合には、gc current blocks received、gc current block receive time統計値
  が増加します。

上記の流れが予想するように、gc cr/current block3-way待機イベントは、3つ以上のノードで構成されるクラスタでのみ発生します。また、クラスタを構成するノードの数とは無関係に、ノード間の通信は、3-wayが最大（リクエストノード：マスターノード：ホルダーノード）ですので、gc cr/current block4-wayのようなイベントは存在しません。
gc cr/current block3-wayイベントの待機現象を解消する手法は、gc current requestイベントと同じです。

gc cr block3-wayイベントなどFixed-upイベントは、P1、P2、P3の値が別途付与されず、Placeholderイベント（ここではgc cr requestイベント）と同じ値を持つものと解釈すれば良いです。

gc cr/ current requestのCheck Point＆Solutionを参照ください。