Re: CCriticalSection - does my thread already have a lock?

From:

"Doug Harrison [MVP]" <dsh@mvps.org>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 20 Jul 2006 12:52:38 -0500

Message-ID:

<l4gvb2pb5aog0ao4m59v05mp0shna8a29m@4ax.com>

On Thu, 20 Jul 2006 10:35:19 -0600, "Dan Baker" <dbmail> wrote:

I think you are right about the race condition. But, I don't really see a
solution to the problem. Since there are multiple threads waiting on the
IOCP, and multiple packets can be queued to the IOCP from the same socket.
The race condition exists between the two threads that wake up from the
IOCP. Is there a known solution to this? Does everyone simply ignore the
race condition?

Could proceed like this:
1. IOCP M fires, thread X wakes up (but a timeslice happens, and the thread
goes to sleep)
2. IOCP N fires, thread Y wakes up
3. Thread Y finds its context and locks it
4. Thread X is too late. The packets are processed in the wrong order.

I would be glad to use a queue, but I don't see where I could add it.

It sounds like it wouldn't make any difference anyway, and you aren't
depending on any particular ordering. To fix the indeterminate ordering at
the IOCP level, you'd have to maintain a queue of waiters using, say, event
objects. Then when the IOCP fires, you'd pop the queue and signal the
event.

--
Doug Harrison
Visual C++ MVP