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

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:1g9vb29v2okt3tlbqbnt3kjiff38h5mslh@xxxxxxxxxx
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.

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.

DanB


.

Relevant Pages

  • Re: [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2
    ... Trond Myklebust wrote: ... Revised patch is attached... ... can take fs locks. ... That sounds pretty unsafe in this context, ...
    (Linux-Kernel)
  • Re: Where is FreeBSD going?
    ... >:the new scheme would be debugged.) ... >:and no nesting or stack context. ... (KSE threads are based upon ... > blocking on I/O events, locks, and mutexes. ...
    (freebsd-hackers)
  • Re: [PATCH] VM: Fix the gfp_mask in invalidate_complete_page2
    ... Revised patch is attached... ... invalidate_complete_pagewants to be called from inside spinlocks by ... can take fs locks. ... That sounds pretty unsafe in this context, ...
    (Linux-Kernel)
  • Re: Notifier chains are unsafe
    ... >I would interpret Keith's comment like this: callout should not be ... We should be able to call notifier_call_chainfrom any context. ... it follows that the callbacks cannot take any locks. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: CCriticalSection - does my thread already have a lock?
    ... I have several worker threads waiting on an IOCP. ... When a worker thread wakes up from the IOCP it does the following: ... hunts for the appropriate context, validates that the context is still ok ... thread is now waiting to lock. ...
    (microsoft.public.vc.mfc)