当前位置：首页 » 软件开发

开发技术指南» 文章正文

    引言： IOCP Thread Pooling in

 

 

IOCPThreadPoolinginC#
iocp thread pooling in c#by william kennedycontinuum technology centerintroduction

【程序编程相关:RealProxy的PrivateInv】

  【推荐阅读:.NET中C#实现C/S架构下的TREE】

【扩展信息:DirectX93D快速上手7】

when building server based applications in c#, it is important to have the ability to create thread pools.  thread pools allow our server to queue and perform work in the most efficient and scalable way possible.  without thread pooling we are left with two options.  the first option is to perform all of the work on a single thread.  the second option is to spawn a thread every time some piece of work needs to be done.  for this article, work is defined as an event that requires the processing of code.  work may or may not be associated with data, and it is our job to process all of the work our server receives in the most efficient and fastest way possible.

 

as a general rule, if you can accomplish all of the work required with a single thread, then only use a single thread.   having multiple threads performing work at the same time does not necessarily mean our application is getting more work done, or getting work done faster.  this is true for many reasons. 

 

for example, if you spawn multiple threads which attempt to access the same resource bound to a synchronization object, like a monitor object, these threads will serialize and fall in line waiting for the resource to become available.  as each thread tries to access the resource, it has the potential to block, and wait for the thread that owns the resource to release the resource.  at that point, these waiting threads are put to sleep, and not getting any work done.  in fact, these waiting threads have caused more work for the operating system to perform.  now the operating system must task another thread to perform work, and then determine which thread, waiting for the resource, may access the resource next, once it becomes available.  if the threads that need to perform work are sleeping, because they are waiting for the resource to become available, we have actually created a performance problem.  in this case it would be more efficient to queue up this work and have a single thread process the queue. 

 

threads that start waiting for a resource before other threads, are not guaranteed to be given the resource first.  in diagram a, thread 1 requests access to the resource before thread 2, and thread 2 requests access to the resource before thread 3.  the operating system however decides to give the resource to thread 1 first, then thread 3, and then thread 2.  this scenario causes work to be performed in an undetermined order.  the possible issues are endless when dealing with multi-threaded applications.

 

if work received can be performed independent of each other, we could always spawn a thread for processing that piece of work.  the problem here is that an operating system like windows has severe performance problems when a large number of threads are created or running at the same time, waiting to have access to the cpu.  the windows operating system needs to manage all of these threads, and compared to the unix operating system, it just doesn’t hold up.  if large amounts of work are issued to the server, this model will most likely cause the windows operating system to become overloaded.  system performance will degrade drastically.

 

this article is a case study comparing thread performance between windows nt and solaris.

http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/zabatta/zabatta_html/zabatta.html

 

in the .net framework, the “system.threading” namespace has a threadpool class.  unfortunately, it is a static class and therefore our server can only have a single thread pool.  this isn’t the only issue.  the threadpool class does not allow us to set the concurrency level of the thread pool.  the concurrency level is the most important setting when configuring a thread pool.  the concurrency level defines how many threads in the pool may be in an “active state” at the same time.  if we set this parameter correctly, we will have the most efficient, performance enhanced thread pool for the work being processed.

 

imagine we have a thread pool with 4 threads and a concurrency level of 1.  then, three pieces of work are queued up for processing in the pool.  since the concurrency level for the thread pool is 1, only a single thread from the pool is activated and given work from the queue.  even though there are two pieces of work queued up, no other threads are activated.  this is because the concurrency level is set to 1.  if the concurrency level was set to 2, then another thread would have been activated immediately and given work from the queue.  in diagram b we have thread 1 running and all of the other threads sleeping with two pieces of work queued.

 

 

so the question exists, why have more than 1 thread in the pool if the concurrency level is set to 1?  if thread 1 in diagram b ever goes to sleep before it completes its work, another thread from the pool will be activated.  when thread 1 goes to sleep, there are 0 threads “active” in the pool and it is ok to activate a new thread based on the concurrency level.  in diagram c, we now have thread 1 sleeping and thread 4 running with one piece of work queued.

 

 

eventually, thread 1 will wake up, and it is possible for thread 4 to still be active.  we have 2 threads active in the pool, even though the concurrency level is set to 1.  in diagram d, we now have thread 1 and thread 4 running and one piece of work still queued.

 

 

the last piece of work in the queue will need to wait until both threads return to a sleeping state.  this is because the concurrency level is set to 1.  as we can see, even though the concurrency level restricts the number of active threads in the pool at any given time, we could have more active threads then the concurrency level allows.  it all depends on the state of the threads in the pool and how fast the threads can complete the work they are processing.

 

a good rule of thumb is to set the concurrency level to match the number of cpu’s in the system.  if the machine our server is running on only has one cpu, then only one thread can be executing at any given time.  it will require a task swap to have another thread get cpu time.  we want to reduce the number of active threads at any given time to maximize performance.  this also leads to scalability.  as the number of cpu’s increase, we can increase the concurrency level because there is a cpu to execute that thread.  this is a general rule and is always a good starting point for configuring our thread pools.

 

the bottom line is, if the cpu is available, and there is work to perform, activate a thread.  if the cpu is not available, do not activate a thread.  one other thing, we need to be careful that we don’t cause a situation where the threads in the pool are constantly being put to sleep for long periods of time during the processing of work.  this may cause all of the threads in the pool to constantly be in an active state, defeating the efficiency of the pool and the performance of the server.

 

the remaining scope of this article will show you how to add iocp thread pools to your c# server based applications.  how to configure the thread pools for your specific application will not be covered.  it is suggested to use the general rules as discussed.

 

system requirements

 

a basic understanding of c# is required t
...   下一页

» 本期热门文章：

· 热门栏目：

» 相关精选文章

» 其它相关：