[MUD-Dev] Re: TECH: Distributed Muds

Jon Lambert tychomud at ix.netcom.com
Wed May 9 11:31:33 New Zealand Standard Time 2001

asnellin at san.rr.com
> On the issue of threading vs polling for network connections, what
> are the practical limits to the number of threads in a system? 
> Disregarding, for a moment, restrictions on data sharing and time
> associated with waiting for locks (which is admittedly a lot to
> disregard) what kind of performance hits come up when you have
> hundreds of threads in a process?

Practical thread limits are very much dependent on hardware, OS and
design.  If you write your thread code well, it's likely you'll hit
the practical sockets limit before you hit the practical threads
limit.  There is no reason to assume one thread per socket.  In some
instances, I have two threads servicing one socket, or 1 thread
serving 5 sockets.  That happens with notification mechanisms.  With
threads the biggest bugaboo (outside of data sharing and locking which
are mostly bigger bugaboos IMO) is heap contention.  Heap contention
causes frequent context shifts.  You get into heap contention when you
allocate many resources and free those resources.  Which is another
reason why threads need to have well defined tasks much like one
designs a function to be cohesive.

I use several methods to minimize heap contention.  One way is after
creating a thread is to use thread local storage to allocate a new
heap for the particular thread.  Subsequent runs of the thread need
not allocate resources.  Another alternative is to move responsibility
of allocating and deallocating resources outside the thread.  For
example I use threads to load classes on and off work queues.
Overloading new and delete in work queue classes to use pre-allocated
memory pools reduces heap contention.  Throwing a critical section in
that has a far less chance of triggering a context switch than
performing the actual allocation and deallocation right then and

Needless to say, I don't think you want to get into a design that
repeatedly creates and destroys threads.  I try create a pool of
threads at the start of my server app and remove them when the app

Note: I use NT so this above may vary with other thread

--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list