Re: CCriticalSection - does my thread already have a lock?
The problem is:
1. Thread 1 needs a guarantee the object doesn't become invalid between
taking its pointer from the list and locking it.
2. Thread 2 needs to "close" the object when it feels like to.
If "validate" you mean checking that the object was not deleted, it cannot
be done. Forget about it.
Objects in the list should have ref count 1.
While you hold the list CS, increment the object's reference count (AddRef).
Then the object cannot become invalid even after you release the list lock.
When thread is done with the object, it calls Release() (outside of lock).
The object's destructor should close the connection.
When the object needs to be closed, it should be removed from the list
(under the list lock) and have Release called on it (outside of the list
lock). The Release() on the last reference will close the connection and
dispose of the object.
Because there is no practical difference whether you still need to process
the received message after you decided to close the connection (if those are
independent, these events might happen in either order), you can either set
a flag in the object to short-circuit the handler (while understanding that
NOT having the flag set should not cause the program to fail), or just
process the message no matter what.
"Dan Baker" <dbmail> wrote in message
news:u3IGW5ArGHA.3776@TK2MSFTNGP02.phx.gbl...
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%238RVXc7qGHA.2180@TK2MSFTNGP05.phx.gbl...
I'd suggest to change your design. In general, you don't sit waiting,
while holding a resource by CRITICAL_SECTION. If a function acquires CS,
it should release it before returning, Your worker threads should arrive
at the schedule point without holding any lock.
I'd suggest using a reference count to track objects instead.
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.
Thanks
DanB
"Dan Baker" <dbmail> wrote in message
news:eD4$Do2qGHA.1976@TK2MSFTNGP04.phx.gbl...
I have a thread pool waiting on an IOCP. Several threads can wake-up at
the same time, and have received data from the exact same socket. I have
the data associated with the socket locked via a CCriticalSection. But,
during shutdown, I want to manipulate the data -- if it isn't locked
down. I am sharing a routine between these two thread-types (worker and
main). This routine can delete the object, IF the current thread has the
lock -- if the current thread does NOT have the lock, then it needs to
flag the object for later deletion.
So, the question: Can I query a CCriticalSection object to determine if
the current thread has a lock?
Thanks
DanB