CppExplore

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

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

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

@rqf
說實話，本文本質很垃圾

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

不錯, 學習

當年寫的這么一個垃圾實現, 大家就不要再繼續留言了 呵呵

支持!

期待

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

樓上不淡定了.
頂樓主.

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

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

@nothing
設置錯誤狀態. 任何狀態下增加錯誤消息處理, 跳轉到錯誤狀態. 和普通狀態/普通事件同質

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

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

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

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

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

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

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

@egmkang
:)

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

支持!!!

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

頂貼支持!

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

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

兄弟，你瘋了。

跟隨高人頂帖

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

兄弟, 你走遠了吧. 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)

請不要發廣告到首頁, 謝謝配合!

@UustCodeIT
session對象和 網絡層的connection對象有一定對應關系的

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

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

@種花得花
是錯了. 應該先執行func,再執行狀態遷移引起的func.

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

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

@種花得花
兄弟看的仔細啊.
如果event產生了state切換,也應該先執行對應的func, 再執行exit func啊.

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

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

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

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

好文!

@zhaojx
很高興你能喜歡我寫的內容, ：）

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

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

不錯 好文!! 期待博主繼續

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

@laohu
"盡量避免pthread_mutex進入競爭態。增大消息隊列的大小，可以有效減少競態條件的出現。 "

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

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

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

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

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

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

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

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

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

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