Re: Fastcode memory managers

From: Martin James (mjames_falcon_at_dial.pipex.com)
Date: 11/17/04 

Date: Wed, 17 Nov 2004 11:37:57 -0000

> Naturally, the complete design is based on atomic memory operations. The
> real difference is that NexusMM will *never* force a thread context switch
> and will *never* hold a thread in a live loop (spin lock) waiting for
> another thread to "release" any a lock.

Good, good, good....

> Forced thread context switches
> (before the allocated time slice is used up) are one of the worst problems
> with multi-threaded programs and seriously affect performance.

* avidable* thread context switches, anyway.

A well
> designed TCP server application, using I/O completion ports, a lock free
> memory manager and generally avoiding the use of everything that could
lead
> to a kernel mode wait state are able to keep 1 thread running per CPU in
the
> system as long as enough requests come in. Serving them without ever
forcing
> a thread context switch and keeping the threads running for long periodes
of
> time (multiple continous timeslices). This will result in the best
possible
> overall performance. But every time there is contention inside the memory
> manager and one of the threads is forced to give up the remainder of it's
> time slice (either by just calling sleep or, even worse, entering a kernel
> mode wait state) there is a noticable drop in performance.

I have tried very hard to avoid as much memory manager action as possible in
my server, but I use CS to protect the pools of buffers, sockets etc :(

AFAIK, you need at least three threads in your IOCP server, one to listen,
one to issue the overlapped reads/writes and one to run the protocol
handler. Even if you have no incoming connections.and the listening thread
is quiecent, you still need one thread either side of the IOCP queue, so
suely you will have context switches?

If a lock-free lock, (!), fails to acquire, you have to do something. If
you are not resorting to a kernel synchro object or using the dreaded
spinlocks, I wonder what you are doing? :)

Rgds,
Martin

Relevant Pages

  • Re: Protected mode multitasking.
    ... > I measured the quantum on my XP Pro machine, ... several versions of NT/2K/XP, workstation and server. ... at which the system clock is updated and the time slice quantum. ...
    (comp.lang.asm.x86)
  • Re: select & gettimeofday
    ... Note that you will get different results with a 2.6.x kernel. ... cause the process to give up its time slice. ... instruction cannot be executed until the scheduler once again ... >difference can be longer than the TIMEOUT. ...
    (comp.os.linux.development.system)
  • Re: Recompiling the 6.06.2 Kernel
    ... recompile the kernel so that it operates on 1000 Hz as opposed to the ... Forgive me for a very noobie question, but what is he asking about here? ... seems to be asking about a time slice length of 1ms). ...
    (Ubuntu)