Re: Ensuring that a thread doesn't own a critical section within a function
- From: "David Schwartz" <davids@xxxxxxxxxxxxx>
- Date: 9 Sep 2006 00:25:36 -0700
Developer wrote:
f() is responsible for destroying a second thread:
thread2_proc()
{
while(! done)
{
// ...
EnterCriticalSection(&cs);
// ...
LeaveCriticalSection(&cs);
// ...
}
}
f()
{
stop_thread2(); // set a flag that is periodically checked in
thread2_proc
WaitForSingleObject(thread2_handle, INFINITE); // wait for
thread2_proc to exit
}
This will deadlock if f() happens to own the critical section and
thread2_proc() is trying to enter it. Changing the WaitForSingleObject
timeout is not an option because f() must ensure the second thread is
truly finished.
You have a semantic problem here, and you are right that the correct
fix is to specify that 'f' cannot be called while holding the lock. The
purpose of the 'f' function is to wait for the second thread to change
state so it can't mess with things. The purpose of the lock is to
prevent the thing the second thread messes with from changing state. So
calling 'f' while holding the lock makes no semantic sense.
DS
.
- References:
- Prev by Date: Re: Ensuring that a thread doesn't own a critical section within a function
- Next by Date: Re: Rendering and physics thread repartition (scheduling?)
- Previous by thread: Re: Ensuring that a thread doesn't own a critical section within a function
- Next by thread: A good policy for avoiding deadlock?
- Index(es):
Relevant Pages
|
