Re: Member variable locking (Critical Section)
- From: "Chris Thomasson" <cristom@xxxxxxxxxxx>
- Date: Fri, 21 Sep 2007 15:47:13 -0700
"Chris Thomasson" <cristom@xxxxxxxxxxx> wrote in message news:zqCdnUaZ09tF2mnbnZ2dnUVZ_gmdnZ2d@xxxxxxxxxxxxxx
"Kürþat" <xx@xxxxxx> wrote in message news:%230NOLY3%23HHA.1188@xxxxxxxxxxxxxxxxxxxxxxx[...]
[...]Is there any better solution?
It depends on the way your handling the state that represents a socket connection and/or the "internal" server state which it may interact with. For instance, you can use exotic/high-performance synchronization method that can allow a plurality of threads to read through a shared list of connections while other threads are concurrently issuing mutations.
Reader threads can access the shared list of connections without using _any_ interlocked rmw or memory barrier instructions... Multi-processor, especially NUMA, even ccNUMA architectures, do NOT take kindly to being forced to execute those type of operations. It can flood the system with costly coherency traffic. Think of the traffic generated by using software and/or hardware based transactional memory schemes:
http://groups.google.com/group/comp.arch/browse_frm/thread/91cb3fbfa2eb362a
Ouch!
.
- References:
- Member variable locking (Critical Section)
- From: Kürşat
- Re: Member variable locking (Critical Section)
- From: Chris Thomasson
- Member variable locking (Critical Section)
- Prev by Date: Re: Member variable locking (Critical Section)
- Next by Date: Re: GINA.dll - Hide Username after sleep?
- Previous by thread: Re: Member variable locking (Critical Section)
- Next by thread: When does GetCurrentDirectory fail to return a drive letter?
- Index(es):
Relevant Pages
|
