Re: IOCP critical sections and mutexes
- From: "anton bassov" <soviet_bloke@xxxxxxxxxxx>
- Date: 16 Aug 2006 20:14:32 -0700
Hi Alberto
It looks like I see the possible reason for crashes......
Every member function takes a "hidden" parameter behind the scenes
(i.e. 'this' pointer).
Although you don't specify it in your argument list, the compiler
generates exacly the same code it would generate if the function in
question did not belong to any class
and took one more argument.
Therefore, if one calls virtual function by its address (for
example,from assembly block) and forgets about this hidden argument, he
will get exactly the same "results" that you describe (i.e. stack
mismatch and invalid 'this' pointer).
If this is the case...... well, then I just wonder why this bug did not
reveal itself on the very first run of your program
Anton Bassov
Alberto Demichelis wrote:
I've just tried your code(a slightly modified version to work in a class
instance) and I get pretty much the same crash. Having to write the assembly
by myself made me realize the I get a null 'this pointer' in my worker
routine.
I mush have done something stupid in my main thread app. I think tomorrow
I'll just rewrite the thing from the ground up.
Anyway thanks a lot for all the help, I was just trying to be sure that
there isn't anything obvious that would make IOCP+critical section blow, and
as suspected was just my fault.
ciao
Alberto
"anton bassov" wrote:
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
.
- References:
- Re: IOCP critical sections and mutexes
- From: anton bassov
- Re: IOCP critical sections and mutexes
- From: Alberto Demichelis
- Re: IOCP critical sections and mutexes
- Prev by Date: Re: Named Shared Memory Problem
- Next by Date: Code sample for reading HDD SMART attributes
- Previous by thread: Re: IOCP critical sections and mutexes
- Next by thread: Named Shared Memory Problem
- Index(es):
Relevant Pages
|
