October 28, 2003
October 20, 2003
POSA2: Asynchronous Completion Token
Introduction
Asynchronous Completion Token是一個design pattern。在asynchronous event-driven application中，我們可能會有一種情況是當asynchronous operation完成後，回傳給initiator時，會不知道是由哪個asynchronous operation所產生的，這時候我們透過Asynchronous Completion Token來解決這個問題。
Context
適用於event-driven的應用程式。在其中使用者非同步地去呼叫operation，接著處理相對應的asynchronous operation的完成事件。
Problem
當client端應用程式透過非同步的方式呼叫一個或多個服務，服務會透過completion event來回應結果給clinet端應用程式。這時候應用程式必須要能夠解多工(demultiplex)這個事件到對應的handler做處理。在此同時，可能會有以下幾個考量因素：
1. service本身不知道client的環境，所以有關completion event demultiplexing的權責要交由 client去處理。
2. 在service跟client之間，我們希望用越少的communication overhead去決定如何解多工 並處理completion event。
3. 我們同時也希望能夠花越少的時間去解多工completion event至對應處理該event的handler
Solution
要解決以上的需求，我們的做法是當我們執行一個asynchronous operation時，同時丟進一個如何處理completion event的資訊。當opeartion完成時，application可以透過個資訊來知道如何處理這個completion event。
更詳細的講，這個特殊的information就是此pattern的重點Asynchornous Completion Token，在其中可能存放了completion handler的function pointer或是object
Structure
Participant and Responsibilities
Initiator
-以非同步的方式呼叫service
-決定completion handler
Service
-提供非同步的服務
Completion Handler
-定義處理非同步運算結果的interface
ACT
-存放處理非同步運算結果的completion handler，以供Initiator處理completion event之用。
Dynamics
1. 在呼叫asynchronous operation之前，Initiator先產生ACT，並指定要處理結果的
completion handler
2. 當Initiator呼叫asynchronous operation時，把參數連同ACT一起傳過去做處理。
3. Initiator在呼叫之後，可以做其他的動作，甚至可以再呼叫其他的asynchronous operation。
4. 當asynchronous operation處理完之後，service回傳結果連同ACT給Initiator。Initiator透過ACT的資訊得知如何解多工此completion event至對應的completion handler做處理。
Conclusion
此pattern感覺有點像是一個信物。在非同步的系統之下，通常很難掌握原呼叫時期的狀態，這時候ACT就扮演了這個類似信物的角色，當Initiator收到此信物後之後則知道如何處理這個completion event。
此token的概念有點像是GoF的Memento，而Memento也有另一個別名也叫做token，但是使用的時機不一樣，Memento是用在紀錄物件的snapshot，供回之後回存之用。而ACT是存放event handler或是一些initiator的狀態資訊，以供處理completion event之用。
October 14, 2003
狂賀..^^
本實驗室三隊參加mobilehero比賽
分別獲得技術組第一名 第三名
應用組第二名
獎金總額160萬....
XD
可惜我沒參加...~><~
October 12, 2003
生於憂患 死於安樂
看完這一期商業週刊的敵人學後
有點啟發
但並不是如何面對敵人
因為我現在根本沒有敵人
而是如何讓自己安逸的生活中取得動力
我放下了商業週刊
腦中沉思了一下
上了研究所之後
我常常失去了前進的動力
整理了一下原因
可能是因為我有了選擇的權利
我選擇了我認為好做的事情
我選擇了我有把握的事情
但是往往在這種前提之下
得到的成長是有限的
在敵人學這篇文章中提到
若身邊沒有可以畏懼的敵人
那我們就會沉溺在安逸之中裹足不前
但是當你的位子搖搖欲墜
後面的人虎視眈眈著你的位子
這時候我們會盡我們所能不被超越
此時的成長是無可限量的
四年的國防役
我也許會選擇一個對我是陌生的環境吧
很少java的影子
盡是我不擅長的領域
但我想把自己丟在一個充滿老虎的草原裡
成為一個善於跑步的斑馬
October 11, 2003
京華城週年慶
終於等到週年慶了
人果然多很多
但是又沒有sogo那麼多
還挺好逛的
還有買了一件鬼爪(牛仔褲啦)
牛仔褲這東西一定要等到週年慶才買
沒打折跟八折差非常多
像我這件就差個600多
挺喜歡的
中直筒帶有復古刷紋
這件打算取代我穿了五年的levis 501吧
因為501已經被我穿的要爛掉了
其實想要買diesel
但是好貴唷...
等我賺錢在來買
現在就先穿中價位的吧..:D
冠軍戰唷
這幾天全部在看職棒的歷史回顧
越看越熱血沸騰
我是龍迷
因為張泰山的關係
現在支持牛
挖 好緊張唷
好久沒有那麼期待一場比賽了
興農加油...:D
October 10, 2003
October 06, 2003
POSA2: Proactor pattern
Introduction
Proactor是一個architectural pattern。此pattern主要針對framework或是OS所提供的asynchronous operations，在這些asynchronous operation結束之後會觸發某個事件(此pattern稱此種事件為completion of asynchronous operations)。在架構在這種framework之上的event-driven的應用程式可以有效率的透過解多工(demultiplex)及分派(dispatch)這些事件到對應的service做處理。
Context
適用於event-driven的應用程式，此應用程式以非同步的方式接收及處理各種service request。
Problem
通常event-driven的應用程式可以透過asynchronous operations來提高整個系統的效能。當這些asynchronous operations完成時，會丟出完成的事件來給外部的應用程式來做處理。因此應用程式要能夠解多工(demultiplex)及分派(dispatch)這些完成的事件給原本呼叫此asynchronous operations的client或是某個應用程式服務做處理。在處理這些解多工跟分派的動作時，我們必須考慮到以下幾點：
1. 為了能夠增加延展性跟減少延遲，應用程式不應該因為處理過長的operation來導致無法同時處理很多的完成事件。
2. 為了能夠有較好的throughput，任何不必要的context switching, Synchronization, data movement都應該要避免。
3. 若未來要整合新的service或是改善暨有的service，所需要花的功夫應該越少越好。
4. 撰寫Service的程式碼中，應該完全不會理會到底層複雜的multi-threading或是synchronization部分的機制。
Solution
我們把應用程式服務分成兩個部分
1. 用非同步的方式處理需要花很長時間處理的operation。
2. 透過completion handler來處理這些非同步的operation的完成事件。
把所有的服務都提供一個asynchronous的operation，並且透過handler來"後置"處理這些asynchronous operation的結果。而asynchronous operation是由initiator來觸發，並且由asynchronous operation processor來處理，當async. operator處理完成後，async. operatrion processor會把completion event塞到completion event queue中。
之後Proactor透過Asynchronous Event Demultiplexer從queue中取出completion event，並且把它解多工並且分派到對應的completion handler做處理。
Structure
Participants and Responsibilities
Handle
-代表的是一個OS提供的resource
Asynchronous Operation
-可以非同步處理的operation
Completion Handler
-定義了一組處理asynchronous operation的介面
Concrete Completion Opeation
-根據應用程式需求的Completion Handler的實作
Asynchronous Operation Processor
-負責執行asynchronous opeartions
-負責把asynchronous operations完成的結果置入到completion queue中。
Completion Event Queue
-負責儲存及存取completion event。
Asynchronous Event Demultiplexer
-提供一個blocking method，向Completion Event Queue等待一個completion event的發生。
Proactor
-跟Asynchronous Event Demultiplexer取得completion event。
-分派event到對應的completion handler。
Initiator
-asynchronous operation的觸發者
-有時候也可以扮演concrete completion handler的角色
Dynamics
1. 首先initiator可能呼叫某個asynchronous operation
2. Asynchronous Operation Processor代理initiator去處理這個asynchronous operation， 此時asynchronous opeartion跟async. operation可以同時進行，兩兩是獨立的。甚至initiator可以呼叫其他的async. operation。
3. 當async. operation完成後，會產生一個completion event。async. operation processor會把這個event塞進此handle所對應的event queue。
4. 當應用程式準備好要處理completion events時，則呼叫proactor的handleEvents()。 此method透過async. event demultiplexer向event queue取得completion event，並且分派到對應的completion handler去做處理。
5. completion handler處理async. event的結果。
Consequences
其實這個pattern在java中不是那麼好實作，書中提到的一些例子都是OS所提供的一些library所提供，如POSIX的aio_*()，或是WIN32的overlapped I/O，completion ports。這些在java中沒有類似的對應，但是也許可以透過nio來模擬。
還有proactor pattern跟reactor pattern很多地方都很相似，都是event handling的pattern，但是event產生的方式跟處理的時機不太一樣。書中有以電話的例子來作比喻。
以Reactor pattern來說，Reactor就像是電話公司，我們的電話號碼就是一個handle，而我們就像是"event handler"向電話公司註冊此號碼"handle"。當電話來時，我們的handle的方式就是拿起電話並開始講話。
Proactor pattern的話就像是語音留言。當我要找我的朋友時，發現他不在，我就留一個語音留言說我再找他。相對於proactor pattern，我就像是一個initiator，執行一個async. operation(語音留言)，並且透過async. operation processor(語音留言系統)。留言之後，我可以做做我自己的事情，逛逛jsptw。之後，我朋友看到我的留言，就回電話給我，此時他所扮演的角色就是completion handler。
October 04, 2003
October 02, 2003
高等計算機圖學
其實滿有趣的
我原本就對3D的東西就滿感興趣的
但是一直都沒有深入研究
最進去聽高等計算機圖學
聽到滿多我想要聽的
課本也不貴
原價才980
在原文書中算便宜的了
真恨研究所為什麼修課要學分費
害我都不太想多修
這學期開始已經超修了...
在超修一門我就窮死
一學期要付塊一萬塊的學分費
唉唉....
不過圖學真有趣
真想多修一點...:D