WaitForSingleObject blocking

[ramialhasan]

If I have some c++ class exported from a Win32 dll, and from some other
console application I created two threads and each thread creates an
instance of the exported class.

My question is related to using WaitForSingleObject from within the dll
class methods and if the two threads called a method in the dll that
blocks on WaitForSingleObject for a long time, then are the two
instances waiting for each other or if returned from
WaitForSingleObject it can continue event if the other thread still
blocked on its instance?

Thanks
Rami

[Doug Harrison [MVP]]

On 18 May 2005 07:44:42 -0700, ramialhasan wrote:

If I have some c++ class exported from a Win32 dll, and from some other
console application I created two threads and each thread creates an
instance of the exported class.

My question is related to using WaitForSingleObject from within the dll
class methods and if the two threads called a method in the dll that
blocks on WaitForSingleObject for a long time, then are the two
instances waiting for each other or if returned from
WaitForSingleObject it can continue event if the other thread still
blocked on its instance?

The threads wait on the object referred to by the HANDLE that you passed to
WFSO to become signaled or for the timeout interval you specified to
expire. Exactly what happens when the handle becomes signaled depends on
the type of the sync object. For example, only one thread is allowed to
acquire a mutex and progress, while the rest remain blocked (modulo
non-INFINITE timeout values) until that thread releases it (or terminates,
in which case it "abandons" the mutex), at which point, another thread can
acquire the mutex.

--
Doug Harrison
Microsoft MVP - Visual C++

[ramialhasan]

Sorry but I mean that the two threads are calling the same method but
from different instances and each instance has its own copy of the sync
object. so they are not waiting on the same event but on different
evemts. But my question is related to DLL processing, so if one thread
is waiting on its own event is the other instances blocked two until
the waiting is released or each thread runs in its own processing
thread?
Regards,
Rami

[Scott McPhillips [MVP]]

ramialhasan wrote:

Sorry but I mean that the two threads are calling the same method but
from different instances and each instance has its own copy of the sync
object. so they are not waiting on the same event but on different
evemts. But my question is related to DLL processing, so if one thread
is waiting on its own event is the other instances blocked two until
the waiting is released or each thread runs in its own processing
thread?
Regards,
Rami

Each thread runs independently. If each thread is using a different
sync object they do not affect each other.

--
Scott McPhillips [VC++ MVP]

[Doug Harrison [MVP]]

On 18 May 2005 13:34:22 -0700, ramialhasan wrote:

Sorry but I mean that the two threads are calling the same method but
from different instances and each instance has its own copy of the sync
object. so they are not waiting on the same event but on different
evemts. But my question is related to DLL processing, so if one thread
is waiting on its own event is the other instances blocked two until
the waiting is released or each thread runs in its own processing
thread?

I'm not sure what you think is special about DLLs. They're pretty much just
chunks of code and data loaded into your process's address space, though
the system does serialize the execution of DllMain functions. As for your
sync objects, if the HANDLEs you pass to WFSO refer to different sync
objects, no synchronization occurs between the two threads when they call
WFSO on their respective HANDLEs. They run independently of one another.

--
Doug Harrison
Microsoft MVP - Visual C++

[ramialhasan]

Thanks for you all, now this is clear