亚洲伊人久久大香线焦,亚洲AV无码之日韩精品,亚洲AV成人无码天堂

新爸爸指南

1、孩子剛出生一兩個月內是睡覺的時間多，清醒的時間少，這是很正常的現象，不用擔心。小毅一開始也是這樣狂睡，我和他媽媽還有點擔心，后來通過查看一些資料才知道這是正常現象。睡的多，長的快。現在7個月了，睡的少了，越來越會鬧騰。
2、孩子出生后24小后出現新生兒黃疸，這也是正常現象，也就是臉色比較發黃，醫生會做檢測，含量在合理范圍內就沒有問題，兩三天內就會推下去，如果超出正常范圍，需要住院治療。小毅那時候檢測出來的含量偏高，本來擔心還要住院，后來還是退下去了。
3、孩子出生后，應該盡快讓他嘗試吃奶，母乳比奶粉好多了。
4、孩子在6個月內，腿腳看起來都是彎的，也就是看起來好像會羅圈腿，其實這也是在正常現象，只要注意不要讓孩子過早的站立增加腿的負擔之外，在6個月之后會慢慢轉為正常。不過小毅太喜歡站了，還是有點擔心了，準備觀察觀察，現在他都能自己借助外物從坐到站。孩子補鈣還是需要的，推薦沖劑類的補鈣產品，小毅用的是愛爾鈣，比較酸，還能接受。補鈣不是吃東西就完事兒，每天曬一些太陽還是必要的。
5、孩子感冒，不要太緊張，如果是沒有超過38度的低燒，先用洗熱水澡的方式來降溫，洗完熱水澡通常會降下來，如果再次上升，采取同樣手段，注意保暖。但是也不是衣服穿的越多越好。如果溫度高于38.5，強烈建議上醫院找專業大夫。但是不要盲目給孩子開藥，低燒完全可以通過物理降溫，小毅到現在就發燒過一次，他媽媽和爺爺太著急，給他開了藥，我知道后“憤怒”地批評了他媽媽，38度以下的低燒物理降溫就可以了，讓他們停了藥，按照我說的去做，沒什么問題。當然，不僅僅要靠物理降溫，也要觀察孩子的精神好不好，精神比較打蔫，跟平常不一樣，那還是上醫院保險。
6、注意給孩子體檢，6個月至少去4次，看看體重和身高是否在正常范圍內。小毅同學的體重和身高都還不錯，媽媽功勞巨大。
7、孩子的防疫計劃是要按照通知去打的，千萬不能忘。
8、孩子咳嗽不能小瞧，可能是呼吸道感染或者輕微感冒，如果不是很厲害，可以考慮食療。風寒喝姜湯，風熱榨梨汁給他喝。
9、孩子從5個月開始要吃蛋黃了，這是因為母乳和奶粉提供的鐵元素不夠了，蛋黃從1/8到一個，逐步添加。在6，7個月的時候，可以考慮將雞蛋做成雞蛋羹給他吃。小毅吃飯很鬧騰，吃個飯也要又蹦又跳，幾個人圍著他轉，無語啊，小皇帝。
10、孩子從2，3個月開始，最好開始榨一些新鮮果汁給他喝，我兒子很喜歡喝蘋果汁和西瓜汁。

11、我兒子6個多月就開始會爬了，這時候要特別小心了，不要讓孩子一個人呆在床上，他爬下床就得摔一跤了。小毅就摔了一次，他媽媽洗衣服，將他一個人放床上，沒想到他會爬，還爬到床下去了：） 聽他媽媽說，腦袋紅了一塊，哭了幾分鐘就沒事兒了。要注意，如果摔了，不會哭起來，趕緊送醫院。

暫時想到這些。。。待補充。

posted @ 2009-08-10 22:24 dennis 閱讀(762) | 評論 (2) | 編輯收藏

最近一直在觀察一個很有趣的現象，在國米超級杯失利后，魔力鳥同學發表的刺激“憤憤”的言論之后各大媒體網站的有趣新聞，這些新聞只是進一步驗證了中國足球妓者的不專業，同樣也讓某些90后球迷興奮地難以言喻，為什么說他們90后？因為只有腦殘到一定程度才會為了這么一場無關宏旨的比賽意淫成那樣。看看性浪網站的意假專題，AC米蘭是祖國江山一片好，而國米的新聞卻是凄凄慘慘切切，實際呢，AC米蘭今年能進前4就知足吧，國米今年聯賽冠軍照拿不誤，當然宇宙無敵王朝隊的超超超新星太多了，30歲以上的新星暫時都不要了。魔力鳥同學捅了馬蜂窩，說了大實話，中國就沒一個專業的足球妓者嘛，除了編造新聞（以《體壇》最牛）、寫寫花邊新聞、跟米盧合影上床（僅限女妓者）之外就不會干點別的，可魔力鳥同學不干了，不僅不合影，還說了實話，還不讓足球妓者們提不專業的問題，你還不讓不讓足球妓者們活呀，全國的足球妓者們統一起來，全國的足球妓者們萬歲，打倒魔力鳥主義，打倒國際米蘭！

posted @ 2009-08-10 20:58 dennis 閱讀(451) | 評論 (0) | 編輯收藏

參加公司半年會的幾點感受

周六參加了公司的半年會，這是我第一次參加年會，2000多號人將學校的禮堂做的滿滿，舞臺也搞的相當華麗。華麗之外的幾點感受：

1、做人，做事，在公司上班工作，都需要使命感和責任感，一家沒有使命感的公司是注定做不長久的。對一份工作沒有使命感和熱情，也是注定做不長久的。

2、我們總是做著自以為幫助別人的同時深深地傷害別人。成人們在感動小女孩的遭遇的同時，也在不斷扯裂她心里的傷疤。一個孩子懂事早熟，這不是什么幸事，而是悲哀。什么時候大人們能不那么粗暴地強加自己的視角給孩子們？

3、老馬果然很能說。

4、參加義工活動還是很有意義的事情，盡管我覺的形式化了。

5、在兩千人面前求婚，事實證明不是那么靠譜的事情。

posted @ 2009-07-27 09:34 dennis 閱讀(843) | 評論 (0) | 編輯收藏

我為什么說豆瓣腦殘

豆瓣是我經常上的網站，我在上面維護我的讀書列表、電影列表和照片，平常有什么想說，偶爾也去那廣播吹水，再加上一幫同好在那，因此逛豆瓣也成了我每天的習慣。當三表說豆瓣是腦殘的時候，俺心里還提它辯解了下，要說他的推薦功能確實非常強大，而且能有這么一個維護讀書計劃的地方還是很不錯的。
不過豆瓣最近的行為，讓我越來越覺它腦殘，理由如下：
一、刪除照片和刪除日志，從來就是一封冷冰冰的郵件通知，“你的XX圖片因不符合豆瓣的圖片策略已被刪除”。我想去看看是哪張照片，但因為照片太多，卻不知道是刪的是哪張了。你丫就不會提供一個回收站啊，或者自動隱藏你認為有問題的照片，你丫刪得干脆，用戶就郁悶了，想知道原因的話，人家豆瓣就是公務猿，一問三不知。

二、動不動就他媽地搞什么“此功能暫停使用”，經常不允許使用廣播，不允許寫日志。我知道不是技術問題，我知道你們迫不得已，但是你們就不知道改變策略，搞個敏感詞過濾或者隱藏五毛們要求刪除的日志或者廣播，而不是停掉功能。靠，你一個網站連正常的功能都提供不了，我上豆瓣干嘛？奸尸啊我。

三、廣告用戶越來越多，經常是一些注冊沒超過一個月，活動記錄沒超過兩條的在書評或者影評蹦跶，將一本垃圾書（比如《敏捷無敵》）或者垃圾電影（比如《赤壁》）夸的跟天上的星星一樣亮晶晶。更甚者是到處加好友，加完了就不斷邀請你參加一些腦殘的廣告活動，煩不勝煩。這個現象的出現一方面說明豆瓣越來越受人關注的，另一方面就不能搞個防騷擾機制？并且對評價結果也應該能做出自動修正，對一些廣告賬戶的評價應該做極低權重處理。為什么是極低？你沒看到嗎，在某部電影的上映檔期內，一大群馬甲可以把他評的跟《教父》一樣，大大誤導廣大人民群眾。

posted @ 2009-07-13 10:56 dennis 閱讀(1337) | 評論 (4) | 編輯收藏

os的進程調度（讀書筆記）

    在多進程、多線程并發的環境里，從概念上看，有多個進程或者多個線程在同時執行，具體到單個CPU級別，實際上任何時刻只能有一個進程或者線程處于執行狀態；因此OS需要決定哪個進程執行，哪些進程等待，也就是進程的調度。
一、調度的目標
1、首先要區分程序使用CPU的三種模式：IO密集型、計算密集型和平衡型。對于IO密集型程序來說，響應時間非常重要；對于CPU密集型來說，CPU的周轉時間就比較重要；對于平衡型程序來說，響應和周轉之間的平衡是最重要的。
2、CPU的調度就是要達到極小化平均響應時間、極大化系統吞吐率、保持系統各個功能部件均處于繁忙狀態和提供某種公平的機制。
3、對于實時系統來說，調度的目標就是要達到截止時間前完成所應該完成的任務和提供性能的可預測性。

二、調度算法

1、FCFS（First come first serve)，或者稱為FIFO算法，先來先處理。這個算法的優點是簡單，實現容易，并且似乎公平；缺點在于短的任務有可能變的非常慢，因為其前面的任務占用很長時間，造成了平均響應時間非常慢。

2、時間片輪詢算法，這是對FIFO算法的改進，目的是改善短程序（運行時間短）的響應時間，其方法就是周期性地進行進程切換。這個算法的關鍵點在于時間片的選擇，時間片過大，那么輪轉就越接近FIFO，如果太小，進程切換的開銷大于執行程序的開銷，從而降低了系統效率。因此選擇合適的時間片就非常重要。選擇時間片的兩個需要考慮的因素：一次進程切換所使用的系統消耗以及我們能接受的整個系統消耗、系統運行的進程數。
    時間片輪詢看上起非常公平，并且響應時間非常好，然而時間片輪轉并不能保證系統的響應時間總是比FIFO短，這很大程度上取決于時間片大小的選擇，以及這個大小與進程運行時間的相互關系。

3、STCF算法（Short time to complete first)，顧名思義就是短任務優先算法。這種算法的核心就是所有的程序都有一個優先級，短任務的優先級比長任務的高，而OS總是安排優先級高的進程運行。
    STCF又分為兩類：非搶占式和搶占式。非搶占式STCF就是讓已經在CPU上運行的程序執行到結束或者阻塞，然后在所有的就緒進程中選擇執行時間最短的來執行；而搶占式STCF就不是這樣，在每進來一個新的進程時，就對所有進程（包括正在CPU上執行的進程）進行檢查，誰的執行時間短，就運行誰。

    STCF總是能提供最優的響應時間，然而它也有缺點，第一可能造成長任務的程序無法得到CPU時間而饑餓，因為OS總是優先執行短任務；其次，關鍵問題在于我們怎么知道程序的運行時間，怎么預測某個進程需要的執行時間？通常有兩個辦法：使用啟發式方法估算（例如根據程序大小估算），或者將程序執行一遍后記錄其所用的CPU時間，在以后的執行過程中就可以根據這個測量數據來進行STCF調度。

4、優先級調度，STCF遇到的問題是長任務的程序可能饑餓，那么優先級調度算法可以通過給長任務的進程更高的優先級來解決這個問題；優先級調度遇到的問題可能是短任務的進程饑餓，這個可以通過動態調整優先級來解決。實際上動態調整優先級（稱為權值）+時間片輪詢的策略正是linux的進程調度策略之一的 SCHED_OTHER分時調度策略,它的調度過程如下：

（1）創建任務指定采用分時調度策略，并指定優先級nice值(-20~19)。

（2）將根據每個任務的nice值確定在cpu上的執行時間(counter)。

（3）如果沒有等待資源，則將該任務加入到就緒隊列中。

（4）調度程序遍歷就緒隊列中的任務，通過對每個任務動態優先級的計算(counter+20-nice)結果，選擇計算結果最大的一個去運行，當這個時間片用完后(counter減至0)或者主動放棄cpu時，該任務將被放在就緒隊列末尾(時間片用完)或等待隊列(因等待資源而放棄cpu)中。

（5）此時調度程序重復上面計算過程，轉到第4步。

（6）當調度程序發現所有就緒任務計算所得的權值都為不大于0時，重復第2步。

linux還有兩個實時進程的調度策略：FIFO和RR,實時進程會立即搶占非實時進程。

5、顯然，沒有什么調度算法是毫無缺點的，因此現代OS通常都會采用混合調度算法。例如將不同的進程分為幾個大類，每個大類有不同的優先級，不同大類的進程的調度取決于大類的優先級，同一個大類的進程采用時間片輪詢來保證公平性。

6、其他調度算法，保證調度算法保證每個進程享用的CPU時間完全一樣；彩票調度算法是一種概率調度算法，通過給進程“發彩票”的多少，來賦予不同進程不同的調用時間，彩票調度算法的優點是非常靈活，如果你給短任務發更多“彩票”，那么就類似STCF調度，如果給每個進程一樣多的“彩票”，那么就類似保證調度；用戶公平調度算法，是按照每個用戶，而不是按照每個進程來進行公平分配CPU時間，這是為了防止貪婪用戶啟用了過多進程導致系統效率降低甚至停頓。

7、實時系統的調度算法，實時系統需要考慮每個具體任務的響應時間必須符合要求，在截止時間前完成。
（1）EDF調度算法，就是最早截止任務優先（Earliest deadline first)算法，也就是讓最早截止的任務先做。當新的任務過來時，如果它的截止時間更靠前，那么就讓新任務搶占正在執行的任務。EDF算法其實是貪心算法的一種體現。如果一組任務可以被調度（也就是所有任務的截止時間在理論上都可以得到滿足），那么EDF可以滿足。如果一批任務不能全部滿足（全部在各自的截止時間前完成），那EDF滿足的任務數最多，這就是它最優的體現。EDF其實就是搶占式的STCF，只不過將程序的執行時間換成了截止時間。EDF的缺點在于需要對每個任務的截止時間做計算并動態調整優先級，并且搶占任務也需要消耗系統資源。因此它的實際效果比理論效果差一點。

（2）RMS調度算法，EDF是動態調度算法，而RMS（rate monotonic scheduling)算法是一種靜態最優算法；該算法在進行調度前先計算出所有任務的優先級，然后按照計算出來的優先級進行調度，任務執行中間既不接收新任務，也不進行優先級調整或者CPU搶占。因此它的優點是系統消耗小，缺點就是不靈活了。對于RMS算法，關鍵點在于判斷一個任務組是否能被調度，這里有一個定律，如果一個系統的所有任務的CPU利用率都低于ln2，那么這些任務的截止時間均可以得到滿足，ln2約等于0.693147，也就是此時系統還剩下有30%的CPU時間。這個證明是Liu和Kayland在1973年給出的。

三、優先級反轉
1、什么是優先級反轉？
    優先級反轉是指一個低優先級的任務持有一個被高優先級任務所需要的共享資源。高優先任務由于因資源缺乏而處于受阻狀態，一直等到低優先級任務釋放資源為止。而低優先級獲得的CPU時間少，如果此時有優先級處于兩者之間的任務，并且不需要那個共享資源，則該中優先級的任務反而超過這兩個任務而獲得CPU時間。如果高優先級等待資源時不是阻塞等待，而是忙循環，則可能永遠無法獲得資源，因為此時低優先級進程無法與高優先級進程爭奪CPU時間，從而無法執行，進而無法釋放資源，造成的后果就是高優先級任務無法獲得資源而繼續推進。

2、解決方案：
（1）設置優先級上限，給臨界區一個高優先級，進入臨界區的進程都將獲得這個高優先級，如果其他試圖進入臨界區的進程的優先級都低于這個高優先級，那么優先級反轉就不會發生。

（2）優先級繼承，當一個高優先級進程等待一個低優先級進程持有的資源時，低優先級進程將暫時獲得高優先級進程的優先級別，在釋放共享資源后，低優先級進程回到原來的優先級別。嵌入式系統VxWorks就是采用這種策略。
    這里還有一個八卦，1997年的美國的火星探測器（使用的就是vxworks)就遇到一個優先級反轉問題引起的故障。簡單說下，火星探測器有一個信息總線，有一個高優先級的總線任務負責總線數據的存取，訪問總線都需要通過一個互斥鎖（共享資源出現了）；還有一個低優先級的，運行不是很頻繁的氣象搜集任務，它需要對總線寫數據，也就同樣需要訪問互斥鎖；最后還有一個中優先級的通信任務，它的運行時間比較長。平常這個系統運行毫無問題，但是有一天，在氣象任務獲得互斥鎖往總線寫數據的時候，一個中斷發生導致通信任務被調度就緒，通信任務搶占了低優先級的氣象任務，而無巧不成書的是，此時高優先級的總線任務正在等待氣象任務寫完數據歸還互斥鎖，但是由于通信任務搶占了CPU并且運行時間比較長，導致氣象任務得不到CPU時間也無法釋放互斥鎖，本來是高優先級的總線任務也無法執行，總線任務無法及時執行的后果被探路者認為是一個嚴重錯誤，最后就是整個系統被重啟。Vxworks允許優先級繼承，然而遺憾的工程師們將這個選項關閉了。

（3）第三種方法就是使用中斷禁止，通過禁止中斷來保護臨界區，采用此種策略的系統只有兩種優先級：可搶占優先級和中斷禁止優先級。前者為一般進程運行時的優先級，后者為運行于臨界區的優先級。火星探路者正是由于在臨界區中運行的氣象任務被中斷發生的通信任務所搶占才導致故障，如果有臨界區的禁止中斷保護，此一問題也不會發生。

posted @ 2009-06-28 13:28 dennis 閱讀(8708) | 評論 (1) | 編輯收藏

最近的工作(mina vs. yanf4j)

     最近工作上是在處理一個線程安全的問題，如何保證對某個資源的訪問是獨占的，不會有并發的隱患。在此過程中接了checkthread，一個線程安全的靜態分析工具，通過annotation標記在編譯期檢查可能的并發隱患，提供了一個eclipse插件，有興趣可以看看他的 example。這個東西有個最不好的地方就是要依賴他的自定義annotation，如果不介意的話還是不錯的選擇，一些常見的隱患都能夠標示出來。
    另外就是去了解了下netty3，jboss的子項目，netty2和mina作者的另一個作品，關注它是因為在他的benchmark中，netty3的表現很優秀，可以看這篇報告《Performance comparision between java nio framework》。大概看了下他的設計思路，其實與mina并無多大區別，不過使用了一些有意思的trick，例如對于write的處理，一般的nio框架都是放入一個隊列，然后注冊寫事件（隊列為空的時候），等待寫，寫通常也是單線程去寫。而netty3做了一個優化，發送消息時同樣有一個隊列，在放入隊列后判斷當前是否正在寫循環中，如果正在寫，那么就注冊一個WriteTask喚醒selector等待寫；如果沒有，那么發送線程立即就去執行這個寫操作，這里的一個好處是少了兩個開銷：注冊事件等待觸發以及線程切換。Selector.wakeup的操作是比較昂貴的，netty3也做了優化。更多東西等待探索。

   山寨nio框架yanf4j已經挺久沒有做出任何改進，這次索性將很多過去考慮不成熟、實踐中證明不必要的代碼刪除和簡化，然后做了個與mina 2.0 -M5的性能對比，采用的netty3作者的benchmark源碼，yanf4j的Echo Server如下：

Echo Server

最后的分析報表，可以看到yanf4j的性能與mina2的性能相近，不過mina在內存使用上非常狠。此外，Xmemcached 1.1.3 將采用最新的yanf4j 0.7.0。

(橫坐標是并發連接數，縱坐標是吞吐量，單位為M/s，測試JDK為1.6.4，具體硬件環境不再詳細列出，與xmemcached的benchmark同)

四張圖分別是在消息長度為64、256、1024、4096字節下的對比。

posted @ 2009-06-26 21:46 dennis 閱讀(5659) | 評論 (4) | 編輯收藏

xmemcached發布1.1.2 (權重、noreply、spring集成）

XMemcached發布1.1.2版本，這一版本仍然是1.1.0版本以來的改進版本，主要的改進如下：

1.支持設置memcached節點權重，權重高的負載相應比較大。

2.為部分協議添加noreply選項，memcached 1.2.5引入了noreply支持，部分文本協議（如存儲，刪除，incr/decr等）允許附加設置一個noreply，表示客戶端不要求memcached應答。這一特性利于批量處理。

3.支持與spring框架的集成。

4.添加verbosity協議，這個協議用于讓客戶端設置memcached的日志輸出級別。

5.一些細節改進。XMemcached從0.5開始就有重連機制，在連接意外斷開的情況下會不斷地自動重連，不過間隔是10秒，現在改成將間隔縮小為0秒以便客戶端能及時連接。改進了JMX支持，可以通過JMX查看節點權重和動態設置節點權重。

6.BUG修復，包括：Issue 35、Issue 36、Issue 37、Issue 38等，具體請看這里

7.去除了對spy-2.4.jar依賴，現在序列化部分已經不再需要spymemcached的這個jar包。

項目主頁：http://code.google.com/p/xmemcached/
下載地址：http://code.google.com/p/xmemcached/downloads/list
wiki地址：http://code.google.com/p/xmemcached/w/list

下面是關于特性的詳細說明，首先是權重的使用，看例子：

MemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil.getAddresses("localhost:12000 localhost:12001"),new int[]{1,3});
MemcachedClient memcachedClient=builder.build();

現在的XMemcachedClientBuilder允許傳入了兩個參數，一個是InetSocketAddress組成的列表，一個是權重的數組，權重數組的元素與列表中的地址一一對應，例如這里就是將"localhost:12000"節點的權重設置為1，而將"localhost:12001"的權重設置為3。同樣在XMemcachedClientMBean中添加了兩個新的方法：

    public void addOneServerWithWeight(String server, int weight)
            throws IOException;

    /**
     * Set a memcached server's weight
     *
     * @param server
     * @param weight
     */
    public void setServerWeight(String server, int weight);

用于動態添加和修改節點的權重。

其次，為了支持noreply選項，MemcachedClient接口引入了系列xxxWithNoReply方法，例如

public abstract void setWithNoReply(final String key, final int exp,
            final Object value) throws InterruptedException, MemcachedException;

    public abstract <T> void setWithNoReply(final String key, final int exp,
            final T value, final Transcoder<T> transcoder)
            throws InterruptedException, MemcachedException;

public abstract void addWithNoReply(final String key, final int exp,
            final Object value) throws InterruptedException, MemcachedException;
public abstract void replaceWithNoReply(final String key, final int exp,
            final Object value) throws InterruptedException, MemcachedException;
public void deleteWithNoReply(final String key)
            throws InterruptedException, MemcachedException;

完整的列表請看changelog.txt, noreply系列方法非常適合于批量處理，比之需要等待memcached應答的效率上提升很多。

第三，與spring的集成，通過XMemcachedClientFactoryBean可以很方便地與spring框架集成，最簡單的配置如下：

   <bean name="memcachedClient"
        class="net.rubyeye.xmemcached.utils.XMemcachedClientFactoryBean">
        <property name="servers">
            <value>localhost:12000 localhost:12001</value>
        </property>
    </bean>

   只要設置servers屬性，那么就可以在任何需要的地方引用memcachedClient這個Bean.更完整的配置參考wiki

   第四，引入了對verbosity協議的支持，通過兩個新方法：

    public void setLoggingLevelVerbosity(InetSocketAddress address, int level)
            throws TimeoutException, InterruptedException, MemcachedException;

    public void setLoggingLevelVerbosityWithNoReply(InetSocketAddress address,
            int level) throws InterruptedException, MemcachedException;

   其中的level就是日志級別。請注意你的memcached版本是否支持這一協議。

    1.1.2是一個承前啟后的版本，按俺的計劃應該還有個1.1.3（專注性能改進和優化），之后才是實現了二進制協議的1.2.0。俺非常希望能有任何人給出任何建議和bug反饋。

posted @ 2009-06-21 14:19 dennis 閱讀(3229) | 評論 (8) | 編輯收藏

Xmemcached實現權重memcached節點（更新）

在JavaMemCached這個memacched客戶端，如果你有多個memcachd節點，你可以設置memcached server的權重，權重高的節點在存儲、獲取等操作就相應占的比重比較大。恰巧我最近也在實現一個類似這樣流控的東西，因此在xmemcached實現了此feature。這個功能暫定在1.2.0的時候發布，但是現在已經可以從svn獲取，只是你需要自己build。

使用方法，與通常調用的唯一區別就是在創建MemcachedClient的時候,

MemcachedClientBuilder builder = new XMemcachedClientBuilder (AddrUtil.getAddresses("localhost:12000 localhost:12001"),new int[]{1,3});
MemcachedClient memcachedClient = builder.build();

XMemcachedClientBuilder新增一個重載構造函數，除了傳入地址列表之外，還可以傳入一個權重數組表示列表中的memcached節點權重，權重數組與地址列表一一對應。這里將localhost:12001的權重設為3，而localhost:12000的權重設置為1。如果沒有提供權重值，默認都是為1。這個feature已經進行了測試，在隨機化測試下完全符合比例要求。這一feature對于是使用標準哈希，還是一致性哈希都有效。

實現原理是添加weight次相同的session存儲在session查找集合里，但是注意這里仍然是只有一個連接的，只是在集合里存儲了這個連接的多份引用，那么在查找session的過程中，找到權重大（引用多）的連接的幾率相應就比較大。

posted @ 2009-06-14 15:25 dennis 閱讀(2026) | 評論 (0) | 編輯收藏

sicp 5.1節習題嘗試解答

5.1 圖就不畫在機器上了，麻煩

5.2 用寄存器語言描述5.1題中的階乘機器，加上了讀取和打印,這里的解答全部在實際的寄存機器中驗證過，但是仍然按照該節的表示法表示。

(controller
fac-loop
   (assign n (op read))
   (assign product (const 1))
   (assign counter (const 1))
iter-loop
   (test (op >) (reg counter) (reg n))
   (branch (label iter-done))
   (assign product (op *) (reg product) (reg counter))
   (assign counter (op +) (reg counter) (const 1))
   (goto (label iter-loop))
iter-done
   (perform (op print) (reg product))
   (goto (label fac-loop)))

5.3 牛頓法求平方根，將這個過程轉化為寄存器語言，第一個版本，假設good-enough?和improve都是基本過程，

;version1
(controller
   sqrt-loop
    (test (op good-enough?) (reg guess))
    (branch (label sqrt-done))
    (assign guess (op improve) (reg guess))
    (goto (label good-enough))
   sqrt-done)

第二個版本，展開good-enough?過程，

;version2
(controller
   good-enough
    (assign t (op square) (reg guess))
    (assign t (op -) (reg t) (reg x))
    (assign t (op abs) (reg t))
    (test (op <) (reg t) (const 0.001))
    (branch (label sqrt-done))
    (assign guess (op improve) (reg guess))
    (goto (label good-enough))
   sqrt-done)

最后，展開improve過程，

;version3
(controller
sqrt-init
   (assign guess (const 1.0))
   (assign x (op read))
good-enough
    ;good-enough
   (assign t (op square) (reg guess))
   (assign t (op -) (reg t) (reg x))
   (assign t (op abs) (reg t))
   (test (op <) (reg t) (const 0.001))
   (branch (label sqrt-done))
    ;improve
   (assign t (op /) (reg x) (reg guess))
   (assign t (op +) (reg guess) (reg t))
   (assign guess (op /) (reg t) (const 2.0))
   (goto (label good-enough))
sqrt-done)

在start之后，從寄存器guess中得到最后結果。

5.4
a)第一個是一個指數計算過程，用到了遞歸，因此需要引入continue寄存器來保存和恢復堆棧，實現與階乘相似，如下

(controller
    (assign continue (label expt-done))
    expt-loop
      (test (op =) (reg n) (const 0))
      (branch (label expt-base-case))
      ;;保存continue
      (save continue)
      (assign n (op -) (reg n) (const 1))
      (assign continue (label after-expt))
      (goto (label expt-loop))
    after-expt
      ;;恢復continue
      (restore continue)
      (assign val (op *) (reg b) (reg val))
      (goto (reg continue))
    expt-base-case
      (assign val (const 1))
      (goto (reg continue))
    expt-done
      (perform (op display) (reg val)))

b) 迭代型的遞歸計算過程，尾遞歸調用，因此不需要continue寄存器來保存和恢復堆棧，這道習題就是希望能分辨非尾遞歸和尾遞歸帶來的寄存機器語言的區別

(controller
    (assign product (const 1))
    (assign n (op read))
    (assign b (op read))
    (assign counter (reg n))
   expt-iter-loop
     (test (op =) (reg counter) (const 0))
     (branch (label expt-done))
     (assign counter (op -) (reg counter) (const 1))
     (assign product (op *) (reg b) (reg product))
     (goto (label expt-iter-loop))
   expt-done
      (perform (op display) (reg product)))

5.5 手工模擬就算了，5.2節就可以機器模擬了

5.6 是有一個多余的save和一個多余的restore操作，請看注釋：

(
   (assign continue (label fib-done))
  fib-loop
   (test (op <) (reg n) (const 2))
   (branch (label immediate-answer))
   ;;compute fib(n-1)
   (save continue)
   (assign continue (label after-fib-1))
   (save n)
   (assign n (op -) (reg n) (const 1))
   (goto (label fib-loop))
  after-fib-1
   ;;compute fib(n-2)
   (restore n)
   ;這里多余，(restore continue)
   (assign n (op -) (reg n) (const 2))
   ;這里多余，(save continue)
   (assign continue (label after-fib-2))
   (save val) ;;save fib(n-1)
   (goto (label fib-loop))
  after-fib-2
   (assign n (reg val))
   (restore val)
   (restore continue)
   (assign val (op +) (reg val) (reg n))
   (goto (reg continue))
immediate-answer
   (assign val (reg n))
   (goto (reg continue))

fib-done)

posted @ 2009-06-11 00:47 dennis 閱讀(1805) | 評論 (1) | 編輯收藏

Scala Ring Benchmark

Scala實現的ring benchmark：

import scala.actors.Actor
import scala.actors.Actor._
import java.util.concurrent.CountDownLatch
case class Message()
class Process(m:Int,p:Actor,latch:CountDownLatch) extends Actor{
  var next=p
  def act{
   loop{
     recvAndSend(m)
   }
  }
  def recvAndSend(count:Int){
     if(count==0){
        latch.countDown()
        exit
     }else{
       react{
         case Message()=>
           next! Message()
           recvAndSend(count-1)
         }
       }
     }
}
object RingBenchmark{
  def main(args:Array[String]){
    start(args(0).toInt,args(1).toInt)
  }
  def start(n:Int,m:Int){
     val latch=new CountDownLatch(n)
     val first=new Process(m,null,latch)
     val p=createProcess(first,n-1,m,latch)
     first.next=p
     val start:Long=System.currentTimeMillis
     first.start
     first!Message()
     latch.await()
     println(System.currentTimeMillis-start)
  }
  def createProcess(p:Actor,n:Int,m:Int,latch:CountDownLatch):Actor={
    if(n==0)
      p
    else{
     val next=new Process(m,p,latch)
     next.start
     createProcess(next,n-1,m,latch)
    }
  }
}

與Erlang版本的比較（單位毫秒),scala版本2.7.4-final，erlang是R13B, windows xp