Re: Member variable locking (Critical Section)
- From: Len Holgate <len.holgate@xxxxxxxxxxx>
- Date: Thu, 20 Sep 2007 07:00:31 -0700
I tend to use a pool of critical sections and use a hash of something
related to the socket (or whatever) to determine which critical
section is associated with which socket; you just do the hash once
when the socket requests a critical section and the 'lock factory'
determines which one to give it. You can then tune the parameters to
your lock factory to determine the most efficient pool size and
profile the hash to ensure good distribution. You need to remember
that you're trading potential lock contention for reduced resource
consumption and then profile the server to tune. If you find that
cross socket lock contention is a major issue then you can simply plug
in a lock factory that gives out unique locks...
--
Len Holgate
http://www.lenholgate.com
On 20 Sep, 12:05, "Kürþat" <x...@xxxxxx> wrote:
Hi,
I have a IOCP based socket server. I instantiate a context object for all
connected clients and put them into an array. Some member variables of
context objects can be accessed out of the IOCP worker threads. So I should
implement a locking mechanism to sync access to those members. I plan to use
accessor methods and critical sections for this purpose but number of
context objects is between 3000-10000. Is it reasonable to initialize 10000
critical sections in a process considering resource issues?Is there any
better solution?
Thanks in advance.
.
- References:
- Member variable locking (Critical Section)
- From: Kürşat
- Member variable locking (Critical Section)
- Prev by Date: Member variable locking (Critical Section)
- Next by Date: Re: IRQL like in ring 3
- Previous by thread: Member variable locking (Critical Section)
- Next by thread: Re: Member variable locking (Critical Section)
- Index(es):
Relevant Pages
|
