青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

有些時候需要給資源分配一個唯一id(32bit or 64bit or CHAR[N]),這里主要說下分配方法問題。

首先我們有個基本前提,如果是單線程分配,那么我們無需下面的方法,直接++value即可(CHAR型無論幾線程都可使用GUID)順序產生不重復序列,下面討論的方法都是多線程下的分配策略:

方法1 win下做簡單的方法莫過于使用InterlocckedIncrement(or InterlockedIncrement64)了,這個調用也很簡單,每次遞增一個,多線程間保證順序遞增絕無重復。此方法只可在單一進程上使用。

 

方法2、區間法,每個線程一次申請一個id區間[m, n],用完了再申請下一個區段,申請的時候鎖一次,其他時間都不用鎖,效率比3略低,比1高。此方法也只可在一個進程上使用,當然如果申請的策略修改一下也可實現多個進程甚至不同機器上的進程之間獨立分配id

 

方法3、方法1雖然簡單但畢竟InterlockedXXX系列函數調用還是有些耗時的,大概50cpu周期級別,更簡單的方法可以使用線程切分原理,如有3個線程參與id分配,我們這樣分配:

線程1 base=1, step =3,序列1,4,7,10,…

線程2 base=2, step=3,序列2,5,8,11,…

線程3 base=3, step=3,序列3,6,9,12,…

絕無重復,調用非常簡單每個線程id = base; base += step;即可。

此方法在單進程上使用很簡單,如果要拓展到多個進程上使用要通過配置來實現,但也是不難的。

 

方法4、如果id可用GUID表示那么方法要簡單一點,生成id直接調用guid生成算法,這個id生成算法即使在多個進程之間甚至不同機器之間也可以保證唯一,也有其價值。

posted @ 2010-10-03 14:13 袁斌 閱讀(1102) | 評論 (0)編輯 收藏

執行100w次的結果(單位:微妙)
------------------------------------------------------------------------------------
線程 volatile讀 volatile寫 InterlockedInc  CS SRWLock共享 SRWLock獨占 互斥量
  1     8            8               35                 66      66                       67       1060
  2     8           76             153                268    134                   148      11082
  4     9           145           361                768    244                   307      23785


volatile讀 long lvalue = gv_value;

volatile寫 gv_value = 0;

InterlockedIncrement(&gv_value);

EnterCriticalSection(&cs);
gv_value = 0;
LeaveCriticalSection(&cs);

AcquireSRWLockShared/Exclusive(&g_srwlock);
gv_value = 0;
ReleaseSRWLockShared/Exclusive(&g_srwlock);

WaitForSingleObject(&g_hMutex, INFINITE);
gv_value = 0;
RleaseMutex(g_hMutex);

如果希望應用程序獲得最佳性能,那么首先應該嘗試不要共享數據,然后依次使用
volatile讀取,volatile寫入,Interlocked API, SRWLock以及關鍵段,當前僅當
所有這些都不滿足要求的時候再使用內核對象。

來自Jeffrey Riched《windows核心編程(5)》的數據,錄在這里備查。

posted @ 2010-10-03 14:12 袁斌 閱讀(271) | 評論 (0)編輯 收藏

從2004年使用iocp開始,嘗試過很多種client生存期管理,最初使用
一個鎖userlock,在sendcomp和recvcomp以及senddata等都用一個鎖,而且是
進去的地方就開始鎖,這種方式最簡單,也產生了最初的版本,之后為
追求更高效率,慢慢演變為使用兩個鎖,readlock和writelock,再之后
演變為send使用一個鎖,recv使用interlockedxxx,再之后演變為
send使用一個cs鎖和一個sending,recv使用一個ref,經歷了如此多種演變。

1、一個鎖userlock, sendcomp recvcomp senddata都用這個鎖。
2、兩個鎖,userlock, sendlock
3、一個鎖userlock+socket查找,鎖范圍比1小,多一次全局查找操作。
4、一個鎖sendlock,一個ref(InterlockedXXX)
   wsasend wsarecv 對象生存期等都用ref計數
5、一個鎖sendlock和一個sending(InterlockedXXX),一個ref(InterlockedXXX)
   wsasend用sending計數,wsarecv等用ref計數

歷經如此幾個版本的修改,鎖的范圍越來越小,interlocked次數越來越少,反應自然
越來越快。
今天為了寫總結文章,拿1 4 5進行了一次比較,1除了大量連接的時候比4 5 反應
慢了很多之外在cpu mem等占用方面幾乎和4 5 相當,也就是說除了實時性方面差一些
其他方面沒有太大差別。
但4 5都是用到了線程級別的內存池,1的測試例程還是用老的內存池,這個差別也
很大,所以綜合地看,雖然做了很多優化卻是花費80%的時間,做了20%的鳥事。

posted @ 2010-10-03 14:12 袁斌 閱讀(245) | 評論 (0)編輯 收藏

5、線程關聯內存池再提速

 

 

上一節已經提到問題,解決辦法是這樣的

struct tm_bufunit

{

        tm_pool *pool;                        //pool指針

        union

        {

                tm_bufunit *next;   //下一個塊指針

                char data[4];           //數據區域

        };

};

 

static void *tm_malloc(size_t size, size_t *osize=NULL)

{

        tm_bufunit *p = (tm_bufunit *)malloc(sizeof(tm_bufunit)-offsetof(tm_bufunit, data)+size);

        if(p)

        {

                p->pool = NULL;

                if(osize) *osize = size;

                return p->data;

        }

        return      NULL;

}

看上面的代碼應該很容易明白,就是將由該池malloc的內存塊也打上統一的標記,這樣由該池分配的任何內存塊都可用最簡單的判斷釋放,省去了查找線程查找目標池的兩次查詢,不光提速了而且解決了上一節提到的那個bug

最終實現的線程關聯內存池通用分配函數tm_new大概相當于malloc 15倍左右的速度,定位到pool之后的newobj相當于malloc 45倍左右的速度。通用函數大致相當于nedmalloc速度的2.6-3倍,直接定位到pool的分配速度大概相當于dlmalloc 2倍。

 

關于線程關聯的內存池還有一些細節問題我沒有展開討論,如free表是每個線程保留一份還是全局保留一份,如果是全局保留一份則涉及到復用的時候如何分配,還有就是tls系列函數我看nedmalloc也在用,我第一版也在用,但后來實測發現這些函數貌似效率不高,后面的版本沒有采用tls系列函數。

關于線程關聯的內存池我寫了5個版本,當然最重要的還是第一個版本,后面的版本除了這一節提到的重要改進之外變化不是很大,最后的第五版增了一些和我的私有lib相關的功能。

 

以前寫文章太少,總是看別人的文章,在網絡時代覺得自己挺自私,這次一鼓作氣,一口氣寫了出來,可能寫得很粗略,不知道有多少人能看明白,如能給讀者一點啟示我將感到很欣慰。

posted @ 2010-10-03 14:11 袁斌 閱讀(257) | 評論 (0)編輯 收藏

4、線程關聯的內存池

 

每每想到單線程下內存池飛一般的速度和多線程下蝸牛一般的速度我就不能原諒自己,為什么差這么多,就不能讓多線程下內存分配更快一點嗎?解決方法有了,那就是讓緩存線程化,各個線程有自己私有的緩存,分配的時候預先從當前線程私有緩存分配,分配空了的時候去全局free表取一組freeunit或直接向系統申請一大塊緩存(各個線程緩存完全獨立),不管具體采用什么方式,速度都大幅度的提高了,雖然還是比單線程下內存池慢了許多,不過比前面提到的多線程內存池以及nedmalloc都要快很多,我的實現大概比nedmalloc1.6 ~ 2倍,離單線程下內存池速度也很近了,只是多了些查找線程id比較線程id等動作而已,基本上達到了自己的目標。

 

看看第一版線程關聯內存池的一些代碼:

 

struct tm_bufunit

{

        tm_pool *pool;                        //pool指針

        union

        {

                tm_bufunit *next;   //下一個塊指針

                char data[4];           //數據區域

        };

};

 

struct tm_gcontrol

{

        tm_bufunit *gfree;

        CRITICAL_SECTION gcs;

 

        tm_gcontrol() : gfree(NULL) { InitializeCriticalSection(&gcs); }

        ~tm_gcontrol()        { DeleteCriticalSection(&gcs); }

        Inline void lock()     { EnterCriticalSection(&gcs); }

        Inline void unlock() { LeaveCriticalSection(&gcs); }

        void free(tm_bufunit *buf)

        {

                lock();

                buf->next = gfree;

                gfree = buf;

                unlock();

        }

};

 

struct tm_memblock

{

        tm_memblock *next;

};

 

class tm_pool

{

private:

        size_t bksize;                   //一個分配塊大小

        size_t onebknum;            //一次分配多少個bksize

        DWORD thid;                          //線程id

        tm_bufunit *next;           //pool中自由塊鏈

        tm_memblock *mbk;              //trunk

        tm_gcontrol gcontrol;     //全局free

       

        friend tm_poolset;

private:

        void expand();

 

public:

        tm_pool(size_t size, size_t bknum);

        ~tm_pool();

 

        void destroy();

        void *newobj();

        static void delobj(void *pbuf);

};

 

class tm_poolset

{

public:

        tm_poolset();

        virtual ~tm_poolset();

 

        //添加分配池

        bool addpool(size_t size, size_t allocnum);

        void *newobj(size_t size, size_t *osize=NULL);

        void delobj(void *pbuf, size_t size);

        void destroy();

 

        tm_pool *findpool(size_t size)

        {

                TMPOOLS::iterator it = tmpools.lower_bound(size);

                if(it != tmpools.end())

                        return it->second;

                return NULL;

        }

protected:

        typedef std::map<size_t, tm_pool *> TMPOOLS;

        TMPOOLS tmpools;

};

 

//公開的數據及函數

extern DWORD tm_tlsindex; //tls索引

 

//app初始化,分配index

void tm_init();

void tm_free();

 

//關聯到該線程

void tm_attach();

void tm_detach();

 

tm_poolset *tm_getpoolset();

//添加trunk

bool tm_addtrunk(size_t size, size_t allocnum);

//tls相關分配

void *tm_new(size_t size, size_t *osize=NULL);

//tls相關釋放

void tm_del(void *buf, size_t size);

 

 

 

.cpp代碼如下:

tm_pool::tm_pool(size_t size, size_t bknum) :

        next(NULL), mbk(NULL),

        bksize(size), onebknum(bknum)

{

        thid = GetCurrentThreadId();

}

 

tm_pool::~tm_pool()

{

        destroy();

}

 

void tm_pool::destroy()

{

        for(tm_memblock *p = mbk; p; )

        {

                tm_memblock *q = p->next;

                free((char *)p);

                p = q;

        }

        mbk = NULL;

        next = NULL;

}

 

void *tm_pool::newobj()

{

        if(! next)

        {

                gcontrol.lock();

                if(gcontrol.gfree)

                {

                        next = gcontrol.gfree;

                        gcontrol.gfree = NULL;

                }

                gcontrol.unlock();

        }

        if(! next)

        {

                expand();

        }

        tm_bufunit *head = next;

        next = head->next;

//     return (void *)head;

        return (void *)head->data;

}

 

void tm_pool::delobj(void *pbuf)

{

//     tm_bufunit *head = (tm_bufunit*)(pbuf);

        tm_bufunit *head = (tm_bufunit *)((char *)pbuf-offsetof(tm_bufunit, data));

        tm_pool *pool = head->pool;

        if(pool->thid == GetCurrentThreadId())

        {

                head->next = pool->next;

                pool->next = head;

        }

        else

        {

                pool->gcontrol.free(head);

        }

}

 

void tm_pool::expand()

{

        size_t unitsize = offsetof(tm_bufunit, data) + bksize;

        size_t size = (unitsize * onebknum + sizeof(tm_memblock));

        tm_memblock *pbk = (tm_memblock *)malloc(size);

        pbk->next = mbk;

        mbk = pbk;

        tm_bufunit *p = (tm_bufunit*)((char *)pbk+sizeof(tm_memblock));

        p->pool = this;

        next = p;

        for(size_t i=0; i<onebknum-1; ++i)

        {

                p->next = (tm_bufunit *)((char *)p+unitsize);

                p = p->next;

                p->pool = this;

        }

        p->next = NULL;

}

 

這一版基本實現了第一步的提速目標,并且每個分配塊還記錄了來自哪個pool,這樣free的時候就省去了查找pool的動作,只是還有一些問題,如何判斷一個內存是來源于malloc的分配還是來源于pool的分配沒有做終結的判斷,而且還留下了一個bug,對于a線程來說,可能只有256512兩個塊的緩存,b線程可能多一個塊1024,這樣a線程分配的1024字節的內存是用malloc分配,到b線程釋放的時候會調用pool釋放,這個bug將在下一章解決。

posted @ 2010-10-03 14:10 袁斌 閱讀(334) | 評論 (0)編輯 收藏

     摘要: 2、多線程內存池   上一節很簡略的說了下單線程內存池,單線程內存池如果要放在多線程環境下使用是不安全的,我們需要進行保護,如何保護,最簡單的方法就是加臨界區,云風的實現里面是用原子操作模擬一個臨界區,我實測跟臨界區性能非常接近,甚至很多時候不如臨界區,所以我就不追求用原子操作模擬臨界區了,還是直接用臨界區最簡單。   class CMemPool { publi...  閱讀全文

posted @ 2010-10-03 13:52 袁斌 閱讀(827) | 評論 (0)編輯 收藏

1、單線程內存池

 

內存池的基本思想是大塊向系統申請內存,內部切割為小塊,內部cache之后有選擇的分配,不夠的時候繼續向系統大塊申請內存,示例代碼如下:

 

struct tm_memblock

{

        tm_memblock *next;

};

class tm_pool

{

        tm_bufunit *next;           //pool中自由塊鏈

        tm_memblock *mbk;              //trunk

};

 

void *tm_pool::newobj()

{

        if(! next)

        {

                expand();

        }

        tm_bufunit *head = next;

        next = head->next;

        return (void *)head;

}

 

void tm_pool::delobj(void *pbuf)

{

        tm_bufunit *head = (tm_bufunit*)(pbuf);

        head->next = next;

next = head;

}

詳細實現建議看云風的內存池,我也不過是學習了它的實現而已。

不要小看了單線程內存池,它是我們走向更復雜應用的基礎,它是我們后面提及的多線程內存池以及線程關聯內存池的基礎。

這種單線程的內存池分配釋放速度是很快的,dlmalloc更快近1倍,大約相當于malloc/free50-100(具體倍率視分配的大小而不同,分配小塊倍率小,分配大塊倍率大)

 

有的朋友可能會考慮使用std::list之類的東西來構建內存池,我奉勸有這種想法的人打住,std::list是效率很低的,此外用一個高層的東西構建底層模塊,總體上屬于本末倒置。

posted @ 2010-10-03 13:51 袁斌 閱讀(356) | 評論 (0)編輯 收藏

0、內存池之引言

 

 

這是關于內存池的一系列簡短文章,當然它不是短期的研究結果,而是長期使用經驗的總結,介紹得可能不會很詳細,一些別人介紹得很細節的東西我就基本掠過。

轉載請署名作者:袁斌

 

內容如下:

1、 單線程內存池。

2、 多線程內存池。

3、 Dlmalloc nedmalloc

4、 實現線程關聯的內存池。

5、 線程關聯內存池再提速。

 

關于內存池有一些經典資源可參考,如早期侯杰《池內春秋》,云風(網易核心開發人員)《我的編程感悟》中提及的內存池,以及許世偉(原金山CTO,現盛大創新院技術專家)關于內存池的系列文章。

 

可以通過QQ345585946和我討論

也可加入我的群:41947449 一起討論游戲開發。

posted @ 2010-10-03 13:49 袁斌 閱讀(312) | 評論 (0)編輯 收藏

前些天無意中在網上看到一篇文章,寫的是幾種腳本語言以及c的速度比較,大意是測試下來lua的速度很慢,只相當于c1/60左右,看了一下測試函數,如下(命名版本1):

 

tkstart = os.clock()

 

local count = 10000000

local accumv = 34.5;

local function iterate (times,accumv)

    if 0 == times then

        return accumv

    else

        return iterate (times - 1, accumv + 2)

    end

end

print(iterate(count,accumv))

 

print(os.clock() - tkstart)

 

這是個迭代調用,理論上這種調用速度不快,所以改寫了一下,命名版本2

 

tkstart = os.clock()

 

local i=0.0;

local function process (ret)

 while(i < 10000000.0) do

 i = i+1.0

 ret = ret + 2.0

 end

 return ret

 

end

 

process(34.5)

print(os.clock() - tkstart)

 

再改寫了一下,版本3,如下:

 

tkstart = os.clock()

 

local i=0.0;

local function process (ret)

 local t = ret

 while(i < 10000000.0) do

 i = i+1.0

 t = t + 2.0

 end

 return ret

 

end

 

process(34.5)

print(os.clock() - tkstart)

 

for循環再改寫了一個版本,版本4,如下:

 

tkstart = os.clock()

 

local count = 10000000

local accumv = 34.5;

local function calc (times,accumv)

        local result = accumv

        for i=1,times do

                result = result + 2.0

        end

        return result

end

print(calc(count,accumv))

 

print(os.clock() - tkstart)

 

簡單測試耗時如下

版本1 0.945

版本2 0.484

版本3 0.475

版本4 0.138   編譯成.out跟直接執行.lua耗時差不多,沒明顯變化。

雖然是一個功能很簡單實現也很簡單的lua函數,但速度差別很大,由此可見不同寫法對執行效率影響很大,跟版本4差不多的c程序執行耗時大約為0.016, lua大致相當于c1/8 - 1/9速度,而不是那篇文章的作者認為的只相當于c1/60

 

從上面四個不同代碼大致可以看出以下問題:

1、 迭代算法是很慢的(版本1)。

2、 While的效率比for慢很多(版本234的比較)。

3、 臨時變量比參數效率高(版本23)。

posted @ 2010-10-03 13:47 袁斌 閱讀(735) | 評論 (0)編輯 收藏

作者:oldworm  可任意轉載但請指明原始鏈接
服務器程序最核心的任務之一就是處理一組任務,在處理一組任務的時候最常見的做法是用線程池,最常見的線程池一般是由一組線程等待在一個信號燈上,有一個任務到達后解鎖一個線程,讓該線程去處理任務,線程處理完成后又回歸到線程池,此做法比來一個任務分配一個線程的古老方法效率高了很多,但這也不是線程池的唯一做法,在windows下至少有三種典型線程池,由于實現上的不同效率相差很大,很有必要作一個比較,以便了解在什么情況下用什么線程池。Windows下常見的線程池實現有以下三種方式,分別是:基于信號燈的傳統線程池(以下簡稱:傳統線程池),系統線程池,完成端口線程池,下面分別介紹三種典型的線程池。
 
傳統線程池
前面已經提到此線程池的典型做法是讓一組線程等待在同一個信號燈上,一旦任務隊列有新任務加入,池中某線程立刻被喚醒并從任務隊列取出一個任務執行,完成后該線程回歸到線程池中。
 
系統線程池
系統線程池是由win2000及之后的操作系統提供的,提供了方便的應用線程池的功能,用在以下幾種場合:
Ø         以異步方式調用方法
Ø         以一定的時間間隔調用方法
Ø         當一個內核對象得到通知時,調用方法
Ø         當一個異步I/O請求完成時,調用方法
 
完成端口線程池
將完成端口和一組線程綁定,利用完成端口的排隊和等待機制實現,由于操作系統對完成端口有專門的優化,我們期待這種模式的線程池有更好的表現。
 
上面簡單介紹了三種典型線程池,但什么情況下用什么線程池,我們先來測試一下效率,后面再總結。我們的測試方法是使用以上三種典型線程池分別執行1000萬小任務,比較執行任務的時間,我們用來測試的小任務是如下的一個函數:
void singletest(void *p)
{
       volatile long l = 10;
       for(int i=0; i<10; i++)
       {
              InterlockedIncrement(&l);
       }
       TESTNODE *pn = static_cast<TESTNODE *>(p);
       if(InterlockedDecrement(&pn->tasknum) == 0)
              SetEvent(gend);
}
一旦任務結束,置一個完成事件。為了測試簡單,傳統線程池和完成端口模式線程池都用了一個固定數目的線程,例子中用的是11,沒有執行動態增減線程之類的調度操作。
 
 
經測試結果如下表:(耗時單位為毫秒)

 

測試次數
傳統線程池耗時
系統線程池耗時
完成端口線程池耗時
1
49250
72234
20391
2
50906
71266
20281
3
50156
73000
20297
4
50437
71157
20000
5
49250
73078
19547
6
49844
73156
19469

 

耗時比約為:5 : 7 : 2,差別巨大
 
從上表可以看出,我們平時最習慣使用的傳統線程池效率并不好,連完成端口線程池一半效率都不到,系統提供的線程池則效率更差,由此可以總結如下:

 

線程池模型
適用操作系統
效率
易用性
傳統線程池
任意
較麻煩,大多數人寫不出好的線程池
系統線程池
Win2000之后
最簡單
完成端口線程池
Win2000之后
較簡單

 

當然不是說系統提供的線程池一無是處,很多時候我們還是可以選擇使用系統線程池的,畢竟它的使用是最簡單的,只是需要最高效率的時候換個選擇,大多數對效率要求不是特別高的場合或你要使用TimerQueue、RegisterWaitForSingleObject、完成端口例程等的時候必須要使用系統線程池,如果不考慮9x系統和nt,那么還是不要使用自己寫的基于信號燈方式的傳統線程池吧,既沒效率也不簡單。當然如果要考慮在各種平臺下都通用,那么基于信號燈方式的傳統線程池幾乎是不二之選。
 
至于以上三種線程池效率差別為什么會這么大,我想各位看過這個數據的都會考慮,具體原因我將另文闡述。
 
 
測試代碼如下:
// CompareThreadpool.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "CompareThreadpool.h"
#include "threadpool.h"
#include "threadgroup.h"
 
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
 
/////////////////////////////////////////////////////////////////////////////
// The one and only application object
 
CWinApp theApp;
using namespace std;
 
HANDLE gend = INVALID_HANDLE_VALUE;
HANDLE giocp = INVALID_HANDLE_VALUE;
 
 
/**
       該例子用來比較測試三種線程池,分別是:
       我自己的線程池
       系統提供的線程池
       標準的完成端口模型
       @author oldworm / oldworm@21cn.com
       2007.5.22
*/
 
struct TESTNODE
{
       volatile long tasknum;    //任務總數目
       DWORD start;                     //任務開始時間
       DWORD end;                      //任務結束時間
};
 
void singletest(void *p)
{
       volatile long l = 10;
       for(int i=0; i<10; i++)
       {
              InterlockedIncrement(&l);
       }
       TESTNODE *pn = static_cast<TESTNODE *>(p);
       if(InterlockedDecrement(&pn->tasknum) == 0)
              SetEvent(gend);
//     printf("num=%u, th=%u\r\n", pn->tasknum, GetCurrentThreadId());
}
 
void mythreadpool(void *p)
{
       singletest(p);
}
 
DWORD WINAPI workitemfunc(void *param)
{
       singletest(param);
       return 0;
}
 
void thgroupfunc(void *pgroup, void *param)
{
//     CThreadGroup *pg = static_cast<CThreadGroup *>(pgroup);
       DWORD dwbyte;
       TESTNODE *tn = NULL;
       LPOVERLAPPED pov;
 
       while(1)
       {
              GetQueuedCompletionStatus(giocp, &dwbyte, (LPDWORD)&tn, (LPOVERLAPPED*)&pov, INFINITE);
              if(!tn) break;
              singletest((void *)tn);
       }
}
 
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
       const int THREADS = 11;
       const int TASKNUMS = 10000000;
       CThreadPool tp(THREADS);
       CThreadGroup tg;
       TESTNODE tn;
       int i;
 
       gend = CreateEvent(NULL, FALSE, FALSE, NULL);
 
       printf("線程池效率比較,分別執行%u個小任務\r\n", TASKNUMS);
 
       //自己線程池方式
       tn.start = GetTickCount();
       tn.tasknum = TASKNUMS;
       for(i=0; i<TASKNUMS; i++)
       {
              tp.Call(mythreadpool, &tn);
       }
       WaitForSingleObject(gend, INFINITE);
       tn.end = GetTickCount();
 
       printf("mythreadpool方式總耗時: %u\r\n", tn.end-tn.start);
 
 
       ////////////////////////////////////////////
       //系統線程池方式
       tn.start = GetTickCount();
       tn.tasknum = TASKNUMS;
       for(i=0; i<TASKNUMS; i++)
       {
              QueueUserWorkItem(workitemfunc, &tn, WT_EXECUTEDEFAULT);
       }
       WaitForSingleObject(gend, INFINITE);
       tn.end = GetTickCount();
 
       printf("系統線程池方式總耗時: %u\r\n", tn.end-tn.start);
 
 
       ////////////////////////////////////////////
       //完成端口形式
       tn.start = GetTickCount();
       tn.tasknum = TASKNUMS;
       giocp = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);
       for(i=0; i<THREADS; i++)
       {
              tg.AddThread(thgroupfunc, NULL);
       }
       tg.Start();
       for(i=0; i<TASKNUMS; i++)
       {
              PostQueuedCompletionStatus(giocp, 0, (DWORD)&tn, NULL);
       }
       WaitForSingleObject(gend, INFINITE);
       for(i=0; i<THREADS; i++)
       {
              PostQueuedCompletionStatus(giocp, 0, NULL, NULL);
       }
       tn.end = GetTickCount();
 
       printf("完成端口方式總耗時: %u\r\n", tn.end-tn.start);
 
       CloseHandle(giocp);
       CloseHandle(gend);
 
       return 0;
}

posted @ 2010-10-03 13:46 袁斌 閱讀(696) | 評論 (0)編輯 收藏

僅列出標題
共4頁: 1 2 3 4 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            中文日韩在线视频| 欧美成人中文字幕在线| 亚洲男人的天堂在线| 亚洲国产高潮在线观看| 国产亚洲女人久久久久毛片| 国产精品天美传媒入口| 欧美三级网址| 国产精品亚洲成人| 精品999在线观看| 亚洲精品中文字幕在线观看| 亚洲欧洲精品一区| 一区二区三区欧美在线观看| 亚洲婷婷综合久久一本伊一区| 亚洲线精品一区二区三区八戒| 亚洲视频在线二区| 亚洲综合首页| 久久青草久久| 亚洲第一视频网站| 日韩视频永久免费观看| 亚洲欧美日韩久久精品| 欧美一区观看| 欧美福利一区| 国产精品视频观看| 亚洲国产精品电影| 午夜国产欧美理论在线播放| 久久免费偷拍视频| 日韩亚洲欧美综合| 久久精品国产综合| 欧美日韩免费网站| 影音先锋中文字幕一区| 中国女人久久久| 免费不卡在线视频| 亚洲一品av免费观看| 巨乳诱惑日韩免费av| 亚洲国产天堂网精品网站| 欧美日韩1区2区| 亚洲直播在线一区| 麻豆精品91| 国产精品理论片在线观看| 亚洲第一福利视频| 欧美影院久久久| 亚洲精品国产精品国自产观看| 性做久久久久久久久| 欧美大色视频| 在线日韩av片| 久久国产主播精品| 中文久久精品| 欧美日韩成人综合天天影院| 今天的高清视频免费播放成人| 亚洲欧美www| 一本久久综合亚洲鲁鲁五月天| 母乳一区在线观看| 一区在线视频| 免费观看不卡av| 久久久久国产精品人| 国产精品久久久久一区二区三区共 | 欧美成年人视频| 伊人蜜桃色噜噜激情综合| 亚洲欧美日韩中文视频| 亚洲精选一区| 欧美色精品在线视频| 一本色道久久综合亚洲精品按摩 | 欧美激情日韩| 久久久久88色偷偷免费| 国产一区 二区 三区一级| 欧美综合77777色婷婷| 亚洲一区二区三区四区视频 | 国产一区二区主播在线| 亚洲综合视频一区| 亚洲综合精品一区二区| 欧美特黄一区| 欧美一区二区高清在线观看| 亚洲一区二区毛片| 国产精品高潮呻吟久久av无限| 一区二区三区.www| 99精品视频免费| 亚洲激情一区二区三区| 欧美在线视频一区二区| 韩国av一区| 欧美电影在线观看| 欧美精品aa| 亚洲天堂成人| 亚洲影视在线播放| 极品尤物一区二区三区| 亚洲激情视频网| 国产精品国产三级国产| 欧美亚洲一区二区三区| 欧美一区二区视频免费观看| 亚洲一区在线视频| 亚洲图片欧美午夜| 国产午夜亚洲精品理论片色戒| 麻豆国产精品va在线观看不卡| 久久免费黄色| 亚洲第一精品电影| 欧美日韩高清在线观看| 午夜伦理片一区| 麻豆9191精品国产| 亚洲一区影音先锋| 久久精品国产一区二区电影| 亚洲区免费影片| 亚洲欧美久久久久一区二区三区| 国产一区二区三区视频在线观看| 亚洲区一区二| 国精品一区二区| 99亚洲一区二区| 韩日视频一区| 亚洲香蕉在线观看| 亚洲国产日韩在线| 欧美在线999| 亚洲欧美日产图| 欧美女同视频| 免费av成人在线| 国产免费观看久久黄| 亚洲免费大片| 一本色道久久88精品综合| 国内精品伊人久久久久av一坑| 99视频有精品| 99一区二区| 欧美激情91| 欧美国产三区| 亚洲风情亚aⅴ在线发布| 亚洲男人的天堂在线aⅴ视频| 亚洲精品国产无天堂网2021| 欧美一区二区在线播放| 午夜精品视频在线观看一区二区 | 亚洲欧洲一级| 亚洲国产岛国毛片在线| 久久国产黑丝| 久久精精品视频| 国产欧美在线视频| 亚洲一区二区三区成人在线视频精品 | 国产农村妇女精品一区二区| 91久久精品国产91久久性色tv| 精品成人久久| 久久精品一区| 嫩草国产精品入口| 一区在线播放视频| 久久精品中文字幕一区| 鲁鲁狠狠狠7777一区二区| 国产一区二区三区精品久久久| 亚洲综合首页| 欧美一区二区精品久久911| 国产精品日韩欧美综合| 亚洲一区久久| 欧美中文日韩| 在线国产精品一区| 免费人成精品欧美精品| 免费在线国产精品| 亚洲色图综合久久| 亚洲国产欧美不卡在线观看| 欧美一区二区三区男人的天堂 | 欧美激情按摩在线| 亚洲精品女av网站| 亚洲精品视频在线播放| 欧美韩国在线| 日韩视频中午一区| 午夜精品免费| 国内综合精品午夜久久资源| 久久国产精品第一页| 美女主播视频一区| 亚洲精品中文字| 国产精品进线69影院| 性色av一区二区怡红| 老色鬼久久亚洲一区二区| 亚洲高清视频在线观看| 欧美精品99| 亚洲直播在线一区| 久久在线免费观看视频| 最新亚洲激情| 国产精品久久久| 午夜宅男久久久| 亚洲国产精品女人久久久| 99精品国产热久久91蜜凸| 国产精品久久久久久久久久免费看| 亚洲自拍偷拍麻豆| 欧美电影免费观看| 午夜在线视频一区二区区别| 国产亚洲一区二区三区在线播放| 久久精品国产亚洲aⅴ| 亚洲精品国产精品乱码不99 | 亚洲国产精品一区二区第四页av| 亚洲视频在线观看网站| 国产欧美亚洲日本| 欧美激情自拍| 午夜久久久久久| 亚洲国产精品va在线看黑人动漫| 亚洲一区二区在线观看视频| 国外成人在线视频| 欧美午夜宅男影院在线观看| 久久国产精品久久久| 在线中文字幕不卡| 亚洲国产一区二区三区高清| 午夜亚洲视频| 亚洲免费精品| 亚洲国产欧美日韩另类综合| 国产精品免费小视频| 欧美成人小视频| 久久精品欧美日韩| 亚洲欧美日韩综合国产aⅴ| 亚洲国产综合在线看不卡|