@小星星 這個函數(shù)本身并不知道它被用于進(jìn)入和退出的地方，他只是處理事件

@sohu 你好！你說的不錯，是“狀態(tài)”的層次，對同一個狀態(tài)機(jī)，更容易符合人的正常思維。
這個理論來自于實踐吧，先考慮最終需要，再進(jìn)行實現(xiàn)。

你提出的基于狀態(tài)機(jī)的層次很不錯，既然想到了這扇門，打開只是實現(xiàn)上的問題，這比“狀態(tài)”層面的有更高抽象，簡單想想，非常不錯

@rqf
說實話，本文本質(zhì)很垃圾

@zhaoyuexian
順其自然，有需要的時候自然會用到

不錯, 學(xué)習(xí)

當(dāng)年寫的這么一個垃圾實現(xiàn), 大家就不要再繼續(xù)留言了 呵呵

支持!

期待

好象有 助聽器 的東西存在, 樓主可以試試.

樓上不淡定了.
頂樓主.

@chipset
站在"造輪子"角度 / "使用輪子" 角度 /"選輪子"角度 看到的東西各有些不同.

@sa
原因: 1) 和linklist相比更節(jié)省內(nèi)存 2)和linklist相比,申請/歸還內(nèi)存更快

@nothing
設(shè)置錯誤狀態(tài). 任何狀態(tài)下增加錯誤消息處理, 跳轉(zhuǎn)到錯誤狀態(tài). 和普通狀態(tài)/普通事件同質(zhì)

書沒賣出去
到是要把cppblog給毀了

兄弟好， 我覺得在cppblog上推銷不如在csdn上有效果

@shenkai
等有時間了 寫點近2年更精彩的內(nèi)容
謝謝捧場

2年前對日志完善了不少,以前的錯誤引導(dǎo)更正下
@田伯光
多進(jìn)程打印問題:
不可以多進(jìn)程打印, 除了寫不能保證原子性,還有文件更換時的問題.
共享內(nèi)存共享log對象可以, 這樣還不如各自打印獨立文件, 同時使用遠(yuǎn)程syslog方式統(tǒng)一打印到遠(yuǎn)程(需要自己實現(xiàn)appender)

動態(tài)生效問題:
可使用ConfigureAndWatchThread類達(dá)到目的, 同時log4cplus中有不少bug,使用這個功能時 要修改不少地方.

@sashion
上上個我的留言里說錯了很多地方.
log4cplus沒有提供延遲輸出的策略, 新的維護(hù)者有計劃增加異步,還沒增加.實現(xiàn)異步延遲打印,需要自己進(jìn)一步封裝實現(xiàn).

"能在core dump 之前把所有的對象都dump到日志中嗎？"
不能. 因log4cplus沒有提供延遲輸出的策略, 日志同步打印,也不存在這個問題. 若自己實現(xiàn)異步延遲輸出的話, 延遲輸出的部分可以使用共享內(nèi)存,另可捕獲信號做一定補(bǔ)償.

@egmkang
:)

不多說了 頂
新年新氣象，前途一定更美好！

支持!!!

@Benjamin
有提升. 一個機(jī)器跑，和多個機(jī)器跑 當(dāng)然是不一樣的.
blog 里很多東西都是簡單概述, 可以找其他有關(guān)協(xié)程的文章看看 :)

頂貼支持!

@金慶
線程之間傳遞指針，基本就是傳遞智能指針。
傳遞id代替就是為了避免智能指針

@chaogu
linux的線程調(diào)度比windows的差, 有資料表明,windows上線程的調(diào)度切換是linux上的1/30大概.
另linux可以把進(jìn)程和cpu綁定,而線程:低內(nèi)核的linux則沒有相關(guān)函數(shù), 2.6小版本內(nèi)核有相關(guān)函數(shù),但綁定不成功, 只有最新的linux內(nèi)核才可以。

兄弟，你瘋了。

跟隨高人頂帖

@cui
......................驚人的一致............

兄弟, 你走遠(yuǎn)了吧. log4cpp的流使用方式就很好啊,類似如此:

#define SLOG(Level,Event) \
do{ \
std::ostringstream _SLOG_BUF_INTERNAL_; \
_SLOG_BUF_INTERNAL_<<Event; \
printf_log(Level,_SLOG_BUF_INTERNAL_.str().c_str()); \
}while(0)

請不要發(fā)廣告到首頁, 謝謝配合!

@UustCodeIT
session對象和 網(wǎng)絡(luò)層的connection對象有一定對應(yīng)關(guān)系的

博主不要生氣, 平常心看待
我想他也是無意說的.

@OnTheWay
c++里的線程安全單例應(yīng)該是典型的雙重檢測.
文中如此實現(xiàn)的話, 每次調(diào)用GetInstatnce都要涉及到加鎖操作, 估計沒人愿意調(diào)用.

@種花得花
是錯了. 應(yīng)該先執(zhí)行func,再執(zhí)行狀態(tài)遷移引起的func.

需要為每個event單獨配置一個event func, 當(dāng)然是這個狀態(tài)對這個event感興趣的時候, 對不感興趣的event, 使用改狀態(tài)的default_func就可以了.

如果每個狀態(tài)只要一個事件回調(diào), 那說明這個狀態(tài)只對一個event感興趣吧(或者你的多個event應(yīng)該合并成一個), 這個時候基本不需要狀態(tài)機(jī),保存一個玫舉的狀態(tài)變量就好了, 這是我的一點看法.

@種花得花
兄弟看的仔細(xì)啊.
如果event產(chǎn)生了state切換,也應(yīng)該先執(zhí)行對應(yīng)的func, 再執(zhí)行exit func啊.

不太明白你的意思. 不過我實際用的狀態(tài)機(jī)的確和文章中的都差異很大,呵呵, 除了整理調(diào)試代碼外,最大的修改 就是狀態(tài)切換時, 不馬上切換, 先將狀態(tài)入隊列,等func執(zhí)行完, 再做實際的state切換,不知道你說的是不是這里的問題.

如果不考慮線程wait和signal的問題，僅僅是讀寫問題，不加鎖可行，我覺得前提是：
（1）只有兩個線程參與，存在point_r 讀指針和point_w 寫指針 兩個變量。
（2）只有讀數(shù)據(jù)線程 寫變量point_r ， 只有寫數(shù)據(jù)線程 寫變量 point_w 。寫就是一個變量的寫操作只在一個線程內(nèi)進(jìn)行，其他線程只讀。

原子性操作不能借助語言層面的volatile實現(xiàn)，必須借助基于硬件的基本原語完成。最近常說的lock_free編程，具體實現(xiàn)是spin_lock，基于CAS原語實現(xiàn)，是因為沒有借助內(nèi)核態(tài)的鎖而著稱。

支持 留名
過幾天也搞個海報出來 呵呵

好文!

@zhaojx
很高興你能喜歡我寫的內(nèi)容, ：）

@cm
試用了內(nèi)存池嗎? 全局內(nèi)存池的話效果不理想,至少linux下全局的是跑不過dlmalloc的. 據(jù)說windows下很容易跑過它自己的malloc子系統(tǒng)吧, 我沒測試過,呵呵.
試試區(qū)分對象內(nèi)存池和線程內(nèi)存池,觀察服務(wù)器穩(wěn)定并發(fā)能力是否有提高,響應(yīng)時間是否有稍許改善,cpu利用率是否平穩(wěn)? 觀察下你服務(wù)器在規(guī)格性能下,是cpu高還是iowait高, 看看系統(tǒng)瓶頸在哪里?

剛頂錯地方了 呵呵. 好文! 期待博主繼續(xù)

不錯 好文!! 期待博主繼續(xù)

@expter
的確不高，呵呵
現(xiàn)在換成線程獨自的定時器了，不再加鎖，容器換簡單的multimap了

@laohu
"盡量避免pthread_mutex進(jìn)入競爭態(tài)。增大消息隊列的大小，可以有效減少競態(tài)條件的出現(xiàn)。 "

前一個句號：減少有人拿到了互斥鎖的時候，再有人申請，此時后來者將陷入內(nèi)核等待。

后一個句號：增大消息隊列長度，可以減少pthread_cond_signal的調(diào)用頻率，該調(diào)用總是陷入內(nèi)核。

“互斥變量的競爭和隊列長度有什么相關(guān)？ ”，沒啥關(guān)系，上面中間是句號， 你當(dāng)成逗號了吧，呵呵。

@搖擺胖胖
你是指這篇blog里的圖嗎？這是甘特圖，用GanttProject畫的 開源的。
時序圖，以前用rose畫，現(xiàn)在改startuml了，也是開源的

@neou
看過。
兩碼事情，8253芯片計時，os里中斷處理。

語言層面沒有這種機(jī)制。
可以用boost 或者自己封裝一層屏蔽os差異

智能指針常用的就是線程間傳遞指針類型數(shù)據(jù)的時候，導(dǎo)致兩個線程不能確定該指針釋放的時間點，所以基本上不加鎖的智能指針用處不大。

已經(jīng)移出首頁。
cppblog基本上比較自由，是否發(fā)首頁由作者自己決定，發(fā)的時候最好斟酌下，謝謝！

博主，這種整篇都是代碼的文章 就不要再往首頁上發(fā)了。全是代碼，很少會有人看的，很多人訂閱了首頁，盡量不要浪費大家的時間。

@大華
莫非是浙江大華的朋友，呵呵