m2014_c->c語言容器類工具列

轉自：http://www.cnblogs.com/sniperHW/category/374086.html

• cocos2dx內存管理
  摘要: cocos2dx基於引用計數管理內存,全部繼承自CCObject的對象都將得到引用計數的能力,可經過調用retain成員函數用於引用計數值,調用release減小引用計數值，當計數值減爲0時銷燬對象.cocos2dx的對象管理是樹形結構的,可經過調用父親節點的addChild成員函數將一個子節點對象... 閱讀全文
  posted @  2014-06-15 19:52 sniperHW 閱讀(37) |  評論 (0)  編輯
• luanet改名爲distri.lua
  摘要: 爲了更好的體現luanet的設計意圖和避免與網上另外一個開源項目重名形成混淆, luanet正式改名爲distri.lua.後需開發工做包括跨平臺,日誌,經過Fork建立新線程正在開發中.新地址:https://github.com/sniperHW/distri.lua 閱讀全文
  posted @  2014-05-05 22:44 sniperHW 閱讀(80) |  評論 (0)  編輯
• epoll實現機制分析
  摘要: 本文只介紹epoll的主要流程而不是分析源代碼，若是須要了解更多的細節能夠本身翻閱相關的內核源代碼.相關內核代碼:fs/eventpoll.c判斷一個tcp套接字上是否有激活事件:net/ipv4/tcp.c:tcp_poll函數每一個epollfd在內核中有一個對應的eventpoll結構對象.其中關鍵的成員是一個readylist(eventpoll:rdllist)和一棵紅黑樹(eventpoll:rbr).一個fd被添加到epoll中以後(EPOLL_ADD),內核會爲它生成一個對應的epitem結構對象.epitem被添加到eventpoll的紅黑樹中.紅黑樹的做用是使用者調用EPOL 閱讀全文
  posted @  2014-03-23 18:43 sniperHW 閱讀(603) |  評論 (0)  編輯
• golang文件傳輸服務
  摘要: 續上篇，本篇介紹一個完整的golang文件傳輸服務器。完整的代碼能夠看服務器,客戶端網絡使用的框架如上篇介紹，這裏就再也不復述.首先定義3個命令碼：const ( request_file = 1 file_size = 2 transfering = 3)request_file用於請求文件傳輸，附帶的命令參數是文件key.file_size用於通告客戶端文件的大小.transfering用於傳輸文件內容，附帶參數是文件內容的二進制數據.服務器的文件配置示例../learnyouhaskell.pdf=haskell../golang.1.1.2.chm=golang../N... 閱讀全文
  posted @  2014-03-07 22:27 sniperHW 閱讀(411) |  評論 (0)  編輯
• golang初體驗
  摘要: 學習golang的時間斷斷續續加起來也有將近一個月了，這期間都是偶看翻幾頁書，沒有寫過實際的代碼.最近作一個app項目，是一個展現類 的軟件，當客戶要看某個圖片時首先向服務器發出一個請求，比對圖片的版本，若是版本與本地一致，則直接顯示，若是版本落後了則由服務 器將最新的版本發送給客戶端.對服務器的需求就是一個簡單的版本比對和文件傳輸,因而打算用go去實現,正好也能夠練練手.在設計上，受到以往框架設計的影響，仍是使用了wpacket,rpacket和共享buffer這個方案，不一樣的地方是go的網絡API不支持gather io,因此buffer沒有被實現爲buffer list,而是一整塊的連續 閱讀全文
  posted @  2014-03-04 21:48 sniperHW 閱讀(796) |  評論 (2)  編輯
• 池式對象分配
  摘要: 有了tcmalloc和jemalloc，在大多數狀況下咱們都沒有必要再本身寫通用的內存分配器(應該說對於極大多數的程序員，都不可能寫出比這個兩個更好的通用內存分配器)。可是，若是對性能有極致的要求，寫一個比通用內存分配器效率更高的池式對象分配器是可能的。一個最簡單也高效的實現就是freelist,每次分配的時候從freelist中get一個，釋放的時候put回去就行了。其實如今單線程下是至關簡單的，也就幾十行代碼。可是在多線程的環境下，問題稍微複雜一點，由於可能有多個線程須要操做freelist,那麼就要用鎖去保護這個freelist,每次get和put的時候都要加鎖顯然會致使freelist 閱讀全文
  posted @  2014-03-01 23:03 sniperHW 閱讀(155) |  評論 (1)  編輯
• 使用kendynet構建異步redis訪問服務
  摘要: ##使用kendynet構建異步redis訪問服務最近開始在kendynet上開發手遊服務端，遊戲類型是生存挑戰類的，要存儲的數據結構和類型都比較簡單，因而選擇了用redis作存儲，數據類型使用string基本就足夠了。因而在kendynet上寫了一個簡單的redis異步訪問接口.###設計理念1.項目時間緊迫，不打算提供一個大而全的訪問接口，只提供一個request接口用以發出redis請求.2.數據在redis中key和value都存儲爲string,由使用者負責將數據序列化成string,從string反序列化回數據.3.服務支持本地訪問和遠程訪問，服務自動根據請求發起的位置將結果返回給 閱讀全文
  posted @  2014-01-20 22:21 sniperHW 閱讀(214) |  評論 (0)  編輯
• Astar算法框架
  摘要: 首先本文並不打算詳細的介紹A*算法，要想大體的瞭解A*算法可參看下面兩篇文章:http://wenku.baidu.com/view/d39faba1284ac850ad02425d.htmlhttp://wenku.baidu.com/view/eaa14f11f18583d049645992.html其次，不用太糾結算法的效率，例如remove_min_pnode函數使用線性探索尋找最小值，實際上可使用二叉堆或別的方法提升執行效率.本文的目的是提供一個較通用的A*框架，用於解決遊戲中的尋路問題.首先看下結構的定義://一個地圖塊節點struct map_node{};//路徑節點stru 閱讀全文
  posted @  2012-12-21 15:43 sniperHW 閱讀(2765) |  評論 (2)  編輯
• C協程實現的效率對比
  摘要: 前段時間實現的C協程依賴棧傳遞參數，在開啓優化時會致使錯誤，因而實現了一個ucontext的版本,但ucontext的切換效率太差了，在個人機器上執行4000W次切換須要11秒左右，這達不到個人要求，因此從新設計了實現，使得在開啓優化時也能獲得正確的結果.而且效率也使人滿意，4000W次切換僅須要730ms左右，足足比ucontext的實現快樂近15倍。下面貼出實現:#include "uthread.h"#include <stdlib.h>#include <ucontext.h>#include <pthread.h>#includ 閱讀全文
  posted @  2012-08-05 22:52 sniperHW 閱讀(680) |  評論 (19)  編輯
• 各類內存分配器的對比測試
  摘要: 最近兩天測試了下tcmalloc,性能的確牛B.因此修改了下固定對象分配器，模仿tcmalloc利用tls作thread cache.下面是在我機器上對本身寫的各個內存分配器與tcmalloc的對比測試，fix_obj_pool finish:326fix_obj_pool finish:165fix_obj_pool finish:168fix_obj_pool finish:164fix_obj_pool finish:174fix_obj_pool finish:164fix_obj_pool finish:174fix_obj_pool finish:185fix_obj_pool f 閱讀全文
  posted @  2012-07-24 11:33 sniperHW 閱讀(452) |  評論 (9)  編輯
• C協程使用舉例
  摘要: 本篇使用上一篇提供的接口，實現一個簡單的協程調度框架.基本思想是，建立一個調度器，用於將處於活動狀態的協程調度運行,調度器維護着一個actived列表,調用spawn建立協程時，將新創建的協程添加到活動列表中。調用schedule將啓動調度器主循環.coro.h#ifndef _CORO_H#define _CORO_H#include <stdint.h>#include "uthread.h"struct coro{ struct coro *next; uthread_t ut; uint32_t id; start_fun st_fun; uint32_ 閱讀全文
  posted @  2012-06-20 16:32 sniperHW 閱讀(351) |  評論 (0)  編輯
• 實現c協程
  摘要: 協程的概念就不介紹了,不清楚的同窗能夠本身google,windows和unix like系統自己就提供了協程的支持,windows下叫fiber,unix like系統下叫ucontext.在這裏重複製造輪子,一是爲了更清楚瞭解協程的實現,二是爲了在windows和unix like系統下都提供一套統一的協程接口.首先介紹下接口,很簡單,只有幾個函數:#ifndef _UTHREAD_H#define _UTHREAD_Htypedef void (*start_fun)(void *); typedef struct uthread* uthread_t;uthread_t uthread 閱讀全文
  posted @  2012-06-19 11:43 sniperHW 閱讀(1522) |  評論 (16)  編輯
• C工具9:定時器
  摘要: 程序項目常常用到定時功能，如網絡程序中，每隔固定的時間將發送緩衝中的數據一次性發往對端.下面介紹一個用posix timerfd實現的定時器， timerfd將定時器當作一個文件描述符，當定時器到時fd變爲可讀，能夠將這個描述符交給epoll監聽，timeout的時候由epoll返回並執行回調.timer.h#ifndef _TIMER_H#define _TIMER_H#define MAX_TIMER 4096typedef struct Timer *Timer_t;typedef void (*timer_callback)(Timer_t,void*);typedef struct  閱讀全文
  posted @  2012-04-20 15:57 sniperHW 閱讀(697) |  評論 (5)  編輯
• ucontext實現的用戶級多線程框架3（實現echo服務器）
  摘要: 前面一篇文章實現了一個搶先式的用戶級多線程框架，如今用那個框架編寫一個echo服務，由於只是個實驗，因此代碼寫得比較雜亂，還有不少可能出錯的狀況也沒有處理，這些在從此的進一步研究中都會慢慢修改，下面是代碼:uthread.h/** brief: 用ucontext實現的用戶級線程框架* author: kenny huang* date: 2009/10/13* email: huangweilook@21cn.com*/#ifndef _UTHREAD_H#define _UTHREAD_H#include <ucontext.h>#include <stdio.h> 閱讀全文
  posted @  2012-04-02 09:32 sniperHW 閱讀(314) |  評論 (0)  編輯
• ucontext實現的用戶級多線程框架2（搶先式多線程）
  摘要: 之前曾經寫過一篇blog，使用linux ucontext實現的用戶級多線程框架.那個框架實現的是協做式多線程序，也就是隻有當正在執行的coroutine主動放棄處理器時，其它coroutine纔有機會得以執行.今天用ucontext實現了一個搶先式的用戶級多線程框架，其主要思想是，用一個物理線程做爲中斷髮生器，以固定的時間間隔發送SIGUSR1信號.另外一個物理線程運行Scheduler和用戶級線程。每當這個物理線程收到信號的時候，就會將執行權切換到Scheduler，由Scheduler挑選一個個用戶線程執行.thread.h// C/C++ header file// Author: .. 閱讀全文
  posted @  2012-04-02 09:31 sniperHW 閱讀(544) |  評論 (0)  編輯
• ucontext實現的用戶級多線程框架
  摘要: 昨天看CN-Erlounge-IV講搞的其中一篇<erlang進程模型在C++中的實踐>,對用coroutine實現用戶態的線程很是感興趣,因而查下資料寫了個簡單的實驗框架,其中schedule算法的實現很簡單,只是遍歷全部能夠執行的coroutine.代碼以下:uthread.h/** brief: 用ucontext實現的用戶級線程框架* author: kenny huang* date: 2009/10/13* email: huangweilook@21cn.com*/#ifndef _UTHREAD_H#define _UTHREAD_H#include <uco 閱讀全文
  posted @  2012-04-02 09:28 sniperHW 閱讀(591) |  評論 (0)  編輯
• 死鎖檢測
  摘要: 曾經參與過的一款網絡遊戲，其服務器使用了異常複雜的多線程序解決方案。致使應用層程序員編寫的代碼很容易就出現死鎖。最終，公司的一個老員工，只能開發了一個死鎖檢測框架，在debug模式下運行時，只要發生死鎖就會打印出調用堆棧。雖說這個框架基本能夠在上線前把全部的死鎖都檢測了出來，可是，規根到底這是設計不合理形成的，多線程利用好了會提高應用的效率，用很差的話，除了影響效率外，對上層開發簡直是災難。下面說說那個檢測方法，其實方法挺簡單的。有兩個容器，一個用於保存線程正在請求的鎖，一個用於保存線程已經持有的鎖。每次加鎖以前都會作以下檢測:1)檢測當前正在請求的鎖是否已經被其它線程持有,若是有，則把那些 閱讀全文
  posted @  2012-04-02 09:26 sniperHW 閱讀(1537) |  評論 (10)  編輯
• 利用用戶級線程提升多線程應用的性能
  摘要: 隨着處理器往多核的發展，多線程被愈來愈多的應用到軟件的開發中。可是若是沒有正確的使用多線程，反而可能會致使軟件性能的降低。多線程程序中一個影響程序性能的因素就是同步。對於windows系統來講，最快的同步方案就是critical_section,critical_section基本上能夠被認爲是一個用戶態的同步機制(特別是設定了spincount,只有在自旋超過了spincount次以後任然不能得到鎖，纔會切入核心態並把當前線程阻塞).但即便是這樣，若是在臨界區中的代碼若是處理時間比較長，任然會致使處理器浪費在自旋上。若是咱們可讓線程在沒法得到鎖的時候就切換線程（固然是在用戶態，切換核心態線 閱讀全文
  posted @  2012-04-02 09:24 sniperHW 閱讀(817) |  評論 (7)  編輯
• C 工具庫8：map
  摘要: 本篇介紹另一個在C++ stl中經常使用的容器map.我打算將map的實現容器和map接口分開,建立map的時候能夠傳遞一個實現了interface_map_container接口的對象指針進來,若是這個參數傳0,則默認使用紅黑樹作實際的容器.這樣作的好處是用戶能夠根據性能需求傳遞本身定製的容器類.例如在遊戲程序中常見的數據表.通常經過一個索引查詢,而且在程序啓動時候將數據所有加載好,在之後的運行中,只會對數據進行查詢,不會作任何修改的動做.在這種狀況下,使用一個數組存放key,val對,再加載完成後對數組排序,後面查詢的時候使用2分法,顯然比用紅黑樹或其它的二叉平衡樹效率更高.好了,下面介紹m 閱讀全文
  posted @  2012-04-02 09:12 sniperHW 閱讀(369) |  評論 (13)  編輯
• C 工具庫7：local_pool
  摘要: 這是個人工具庫中最後一個內存分配相關工具,其主要用途是，在某一函數或一個做用域中須要使用動態內存，出了這個做用域以後，立刻就釋放這些分配的內存.其主要工做模式是，函數開始時分配一大塊內存，由分配器管理，函數中須要使用的動態內存全都由分配器從這塊大的內存中分配出來，分配出來的內存無需free，函數返回以前銷燬分配器，由分配將開始分配的大塊內存釋放.local_pool.h#ifndef _LOCAL_POOL_H#define _LOCAL_POOL_Htypedef local_pool *local_pool_t;/** pool:外部傳進來的大內存塊首地址，當這個參數不爲0時,* ... 閱讀全文
  posted @  2012-04-02 09:09 sniperHW 閱讀(202) |  評論 (0)  編輯
• C 工具庫6：通用內存分配器
  摘要: 本篇將介紹一個通用內存分配器的實現.上一篇的開頭已經介紹過,這個實現是組合first fit pool和fix_obj_pool以處理不一樣大小的分配請求.首先看由fix_obj_pool返回的內存的頭結構:struct head_fix{unsigned short idx;/*0-255,表示在fix_objs的下標*/unsigned short chunk_idx;};這個頭不會返回給上層應用,是給釋放內存使用的.由於內存的請求是對齊到4字節的,小於1024字節的請求,被分紅256個分配大小,分別是4,8,12,....1024.每一個大小的請求由一個fix_obj_pool處理.idx的 閱讀全文
  posted @  2012-04-02 09:07 sniperHW 閱讀(285) |  評論 (0)  編輯
• C 工具庫5：first fit pool
  摘要: 本篇介紹通用內存分配工具的另外一個組件,first fit momery pool,也就是首次適應內存分配器。相對於best fit 算法，一般來講first fit具備更好的平均性能，具體分析可參考kunth計算機程序設計第一卷2.5的討論.個人通用內存分配器準備組合使用fix obj pool和first fit pool.fix obj pool用於處理1-1024字節的小內存請求.這裏分配的內存是對齊到4字節的.而對於1-1024字節之外的大內存塊請求，將交給first fit pool處理.爲了加快free時的處理效率，將對fix obj pool作一個小處理，具體將在下篇通用內存分配 閱讀全文
  posted @  2012-04-02 09:06 sniperHW 閱讀(236) |  評論 (2)  編輯
• C 工具庫4：變長數組(vector)
  摘要: vector.h#ifndef _VECTOR_H#define _VECTOR_Hstruct vector;struct vector *vector_create(unsigned int val_size,unsigned int reserve_size);struct vector *vector_copy_create(struct vector*);void vector_copy(struct vector*,struct vector*);void vector_reserve(struct vector*,unsigned int);void vector_destroy 閱讀全文
  posted @  2012-04-02 09:03 sniperHW 閱讀(269) |  評論 (0)  編輯
• C 工具庫3：固定大小的 obj pool
  摘要: 對大小固定的對象提供的對象池工具，當對內存分配的請求大小不固定時，使用其它的通用內存池.fix_obj_pool.h#ifndef _FIX_OBJ_POOL_H#define _FIX_OBJ_POOL_Hstruct fix_obj_pool;/** obj_size:對象大小* default_size:默認對象池大小* align4:返回的對象地址是否須要對齊到4字節*/extern struct fix_obj_pool *create_pool(unsigned int obj_size,int default_size,int align4);extern void destro 閱讀全文
  posted @  2012-04-02 09:02 sniperHW 閱讀(420) |  評論 (1)  編輯
• C 工具庫2：異常處理
  摘要: 使用setjmp,longjmp實現的C與言異常處理框架。提供 拋出異常，捕獲異常等功能。exception.h#ifndef _EXCEPTION_H#define _EXCEPTION_H#define except_alloc_failed 1 //內存分配失敗#define except_list_empty 2 //list_pop操做,當list爲空觸發//............#endifexcept.h#ifndef _EXCEPT_H#define _EXCEPT_H#include <setjmp.h>#include <stdio.h>#incl 閱讀全文
  posted @  2012-04-02 09:00 sniperHW 閱讀(193) |  評論 (0)  編輯
• C 工具庫1：list
  摘要: 近來考慮將項目基礎框架的開發語言從C++換成C，免不了要編寫一大堆的基礎工具。本篇爲第一篇，list,提供的接口和操做方式與std::list類似.後續將會陸續貼出map,vector,memory pool,hash_table等工具。list.h#ifndef _LIST_H#define _LIST_Hstruct list;struct node;struct fix_obj_pool;struct list_iter{ struct node **next; struct node *n;};struct fix_obj_pool *list_create_obj_poo... 閱讀全文
  posted @  2012-04-02 08:55 sniperHW 閱讀(367) |  評論 (3)  編輯
• C++反射實現
  摘要: C++實現反射的一個簡單實驗，考慮並不充分。typelist.h#ifndef _TYPELIST_H#define _TYPELIST_Hclass NullType {};//Typelisttemplate <class T, class U>struct Typelist{ typedef T Head; typedef U Tail;};template <class TList, class T> struct IndexOf; template <class T>struct IndexOf<NullType, T>{ enum { 閱讀全文
  posted @  2010-11-24 15:11 sniperHW 閱讀(101) |  評論 (0)  編輯
• 消息隊列的設計
  摘要: 在網絡服務器的設計中,常用多進程/多線程.這就涉及到在進程/線程間共享數據.如今咱們假設一個場景,一個進程/線程負責處理網絡收發,一個或多個進程/線程處理收到的網絡數據包.顯然,咱們能夠在每一對協做進程/線程間添加一個隊列,將數據添加到隊列中,以實現兩個進程/線程的協做.咱們的消息隊列主要的設計目標有三個:1)要可使用在進程與進程和線程與線程之間.當在進程之間通訊時,咱們的消息隊列將會被放在共享內存中.2)避免使用鎖機制,其一方面緣由是鎖的開銷較大,另外一方面是由於,對於在共享內存中使用消息隊列時.若是一個進程得到鎖以後崩潰,另外一個進程將得不到任何的通知.當它要得到鎖的時候,將會阻塞在永遠 閱讀全文
  posted @  2009-06-09 16:23 sniperHW 閱讀(387) |  評論 (8)  編輯