Hello Nick and Peter
Thread.Join() is exactly the same as waiting on the thread handle
in unmanaged code.
This is right, at least in the current implementation of CLR.
It can be proved with a test: Break the process using windbg when your
thread is blocked with Thread.Join. Look at the blocked thread's call-stack
and find the parameters that were passed to ntdll!ZwWaitForMultipleObjects.
The first parameter is the handle count, and the second parameter points to
the handle values. Get the handle value that the thread is waiting on using
the dd command. Then get the type of that handle: !handle <handle value>.
It dumps " Type Thread", which proves that the thread is waiting
on a thread handle, instead of an additional handle like mutex, or event.
Because .NET threads are different from OS threads:
http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspx
It's not reliable to use.NET threads and OS thread handles in the same time
because .NET threads may become irrelevant to OS threads in future
implementations of CLR. The safest way is to either completely use OS
threads by p/invoking thread APIs like
http://www.pinvoke.net/default.aspx/kernel32/CreateThread.html, or
completely use .NET threads and its sync functions.
Let me know if you have any other questions or concerns.
Have a nice day!
Regards,
Jialiang Ge (
[email protected], remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
