Re: IOCP critical sections and mutexes

Completion ports do not use user mode apcs for delivering completion
indications, those are pulled from the queue via GetQueuedCompletionStatus
only - never simply by entering an alertable wait.

BTW, for the record, both the user mode accessible mutex and critical
section objects allow for recursive acquisition on a single thread without
any ill effects (provided the region guarded by the synchronization object
in question is prepared to handle this case of course).

--
Ken Johnson (Skywing)
Windows SDK MVP

"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:O88XxAIwGHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
Well IOCP uses APC's so the question is are you creating a situation where
the critical section is recursively acquired by a thread through the IOCP?
Since mutexes are not recursively acquired I suspect that is the problem.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



"Alberto Demichelis" <AlbertoDemichelis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:F0926EBC-3AC8-4103-8F3A-E5DE707C67D1@xxxxxxxxxxxxxxxx
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
    ... just deleted object. ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... the critical section is recursively acquired by a thread through the IOCP? ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... instance) and I get pretty much the same crash. ... I mush have done something stupid in my main thread app. ... My packets never go over 2k in size. ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)
  • Re: Creating a simple windows messaging app
    ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no ...
    (microsoft.public.vc.mfc)
Loading