Re: IOCP critical sections and mutexes

Hi mate

As it has been suggested by one of the participants, your code may
have some hidden
bug that reveals itself only under the stress and when critical section
is used (because, as it has been suggested, "mutexes make the thing
much slower" ). For the fun of doing it, you can run a small test -
instead using system-provided critical section, you can try your own
version of it. If the program crashes, then there is some bug in your
code, and if it does not, then there must be some problem with critical
section.

The code below is very simplistic (but fully functional) equivalent of
critical section:


//this variable must be originally initialized to 0xFFFFFFFF
DWORD counter;

//this is an open handle to auto-reset event that must be originally
initialized to non-//signaled state

HANDLE event;

void EnterSection()
{

_asm

{

lock inc counter
jnz skip:

}
return;

skip: WaitForSingleObject(event,....);

}


void LeaveSection()
{

_asm

{

lock dec counter
jnl skip:

}
return;

skip: SetEvent(event);

}

This code is lightning fast, so that if the above suggestion is
correct, you are guaranteed to crash. If everything works fine, then
there must be some problem with critical sections


Anton Bassov








Alberto Demichelis wrote:
Hi all, I'm writing a server app based on a UDP protocol. I have to handle a
large number of packets
per second so I'm using IOCP for handling my socket. Until this week, I
thought I'd nailed my IOCP
routines but I recently started some preliminary stress test on a new server
machine and I'm getting
a strange crash that is driving me mad.

My scenario is simple, I have a single UDP socket, I spawn 2 threads per
processor and I have a maximum
concurrency in my CP set to 'number of processors'. I cap a max 2 read
requests per thread and max 5 write
requests queued per thread. My packets never go over 2k in size.
Each IO thread does very little work, just checks if the UDP packet is
actually a valid frame for my app
then pushes it in a queue that will be later processed by my main app
thread(is a realtime simulation).
The queue access is sycronized using a critical section(I'm also testing
with a mutex)

My crash happens when I push a packet in the queue that goes to the app. The
thing that drives me crazy is that
only happens on my dual Xeon (with hyperthreading Win Server 2003) and only
if I use critical sections as sycronization.
If I use a mutex instead it works fine.

My test is very simple. I generate about 10Mb of traffic that will be sent
to the app. Eventually on my dual xeon
I'll get an exception that looks like a pure virtual function call. I
reproduced the crash many time and explored
the stack and everything looks just fine, except that my stack seems to be 4
bytes shifted(but I assume is just VS's Debugger that
gets a bit confused with release builds). The problem seems to be around the
critical section.
The critical section version crashes almost immediately, the mutex version
has been running for hours onder heavy stress and is flawless.

So far I always tested it on my dev machine (dualcore pentium Win XP pro)
and even if I generate a lot of traffic the
app just works fine both with critical section or mutex. On single core
machines obviuosly works well too.
If I use single threaded network IO everthing works fine so I'd exclude a
bug in the app itself.

Does anybody have any idea of what could cause this? is there something that
I shouldn't do with critical sections?
I'm really curious because I really don't understand the mutex as a solution.

thanks for your time
Alberto

.

Relevant Pages

  • Re: IOCP critical sections and mutexes
    ... It is well-known fact that some otherwise invisible bugs reveal ... themselves only under the stress. ... works perfectly well even under the stress if you use mutex instead ... then pushes it in a queue that will be later processed by my main app ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Display a message each time functions are called
    ... This app is basically an e-Learning and content ... That does not sound like a problem with client-side scripting either. ... Not a client-side script problem either, unless there was a bug in the user ... very well for reporting: ...
    (comp.lang.javascript)
  • Re: pause simple but usefull
    ... than a C compiler that sees much heavier use (hence bug reports). ... I am of course speaking in the context of if more people would do asm and work together on it, this would safe time for them, and for their users. ... It is quite simple to make an app run correctly from a single directory, without ever toughing the registry and ect. ... Now try to imagine we download and install, something like may 10-100 apps a year, with updates and etc, and each spend from 10 seconds to several minutes just to install, some even spend the same amount of time to unistall. ...
    (alt.lang.asm)
  • Re: IOCP critical sections and mutexes
    ... those are pulled from the queue via GetQueuedCompletionStatus ... BTW, for the record, both the user mode accessible mutex and critical ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... mismatch and invalid 'this' pointer). ... instance) and I get pretty much the same crash. ... I mush have done something stupid in my main thread app. ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)