Re: CCriticalSection - does my thread already have a lock?
On Thu, 20 Jul 2006 09:08:18 -0600, "Dan Baker" <dbmail> wrote:
My current design is as follows:
I have several worker threads waiting on an IOCP.
When a worker thread wakes up from the IOCP it does the following:
1) locks down the list of contexts
2) hunts for the appropriate context, validates that the context is still ok
3) unlocks the list of context (to avoid deadlock)
4) locks the context (which could wait on another thread that is already
processing a packet)
The confusion happens at this point. The "other" worker thread that had the
context locked could determine that the connection needs to be closed (due
to a number of reasons). If this other worker thread determines to close
the connection, it also needs to invalidate the context that the above
thread is now waiting to lock. As soon as this other worker thread unlocks
the context, the above thread will wake up from the blocked lock call, with
a context which has become "invalid" (closed).
I will look in reference counting. Any other suggestions would be welcome.
Couldn't the "context" maintain a flag indicating its state? Or you might
be able to maintain a mapping between context addresses and (invalid)
state. This former would of course be performed under the protection of the
context lock, while the latter would require a more global type of lock if
the context lock is just for a single context.
BTW, it sounds like your locking protocol has a sort of race, in which the
events could proceed like this:
1. IOCP M fires, thread X finds its context
2. IOCP N fires, thread Y finds its context
3. Thread Y locks its context
4. Thread X locks its context
If order is important, you might need to use a queue.
--
Doug Harrison
Visual C++ MVP