Re: Semaphore limitations
- From: adebaene@xxxxxxxxxxxxxxxx
- Date: 1 Mar 2007 04:25:12 -0800
On 1 mar, 09:38, j...@xxxxxxxxxxxxxxxxxxxx ("Jeffrey Tan[MSFT]")
wrote:
Hi,
Besides Kevin and Arnaud's information, I have some other comment below:
Basically what I am doing is queing requests (threads) for an object on a
per user basis
Do you spawn a thread per user to serivce the request? So do you may have
1000 threads waiting in the ISAPI extension? If so, it may have much
performance hint on the server. The real concurrent threads are the number
of CPUs on the server. So if you have 4 CPUs, there are 4 threads can be
executed at the same time. Most of the 1000 threads are in the sleep status
while costing a lot of memory for persisting their state and data
structure.
You may consider to implement some type of thread pooling and thread
reusing. Normally, I/O completion port is very suitable for this task. The
idea is after one thread has finished the previous work, it can be reused
to service the later user request, so we really should use a smal amount of
threads to service large number of requests. Also, due to the reduce of the
threads count, your design may need fewer mutex or critical sections.
The OP certainly should consider using thread pooling for performance
reasons, but this won't change the need to synchronize accesses to
each of the 1000 object per user, in order to guarantee each object
coherency.
Arnaud
MVP - VC
.
- References:
- Re: Semaphore limitations
- From: Kevin
- Re: Semaphore limitations
- From: "Jeffrey Tan[MSFT]"
- Re: Semaphore limitations
- Prev by Date: Re: Get path from dir handle
- Next by Date: ASP_NET OpenProcess
- Previous by thread: Re: Semaphore limitations
- Next by thread: Re: Semaphore limitations
- Index(es):
Relevant Pages
|
