Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 30 January 2023 | Live, Online |
Developing Minifilters | 20 March 2023 | Live, Online |
Internals & Software Drivers | 17 April 2023 | Live, Online |
Writing WDF Drivers | 22 May 2023 | Live, Online |
Comments
_beginthread and _beginthreadex is full of holes and missing information.
I've sent several request for updates to the docs to MSDN and they've been
pretty responsive.
There is no need to call _endthreadex unless you want to kill your thread
pre-maturely (before it returns naturally). If you let it return naturally,
you'll find that the thread count does return to normal and things do get
cleaned up properly.
If your thread count is continually rising, they something else is going
wrong. Either you think you're returning but you're not, or you're creating
more threads than you think you are.
After your thread exits, you'll need to close it's handle.
That means that you should have saved it when you called _beginthreadex in
the first place.
You already know how to determine when the thread is done, right?
WaitForSingleObject.
If you have many threads, you can WaitForMultipleObjects.
As far as who should do the waiting, the easiest way is to let the caller of
_beginthreadex do the waiting. Note that while you're waiting, the thread
that calls Waitxxxx is blocked, but the threads it's waiting on are not. If
you don't want the caller to block, execute it in a loop and give it a
timeout parameter - I believe that this method is relatively efficient too,
not consuming to many cycles if your timeout is reasonable.
When you're writing threaded code, logging is essential to maintaining your
sanity.
I like to write statements to a log file with the thread ID of the process
so that I can see the beginning and ending of the thread. _beginthreadex's
last parameter is an address of a variable that will get the thread id,
assuming the thread is created properly. Pass that to your thread as an
argument, and your thread knows who it is. (Note that the _getpid() function
does not return the thread id as I'm told it does under most Unix flavors,
but rather returns you your process ID as it's name implies).
ERX
>-----Original Message-----
>From: Barak Mandelovich [mailto:[email protected]]
>Sent: Monday, April 24, 2000 8:07 AM
>To: NT Developers Interest List
>Subject: [ntdev] WinNT handles problem using threads
>
>
>Hi everybody!
>
>This is not a kernel question, but still - I find it quite
>interesting to be asked in this forum:
>
>I have a multithreaded program: a main thread,
>that creates new threads upon request, using
>the _beginthreadex() function.
>
>_beginthreadex is called with a very simple function
>that does nothing but Sleep(), and then returns.
>
>When I look in the task manager, I see that the handle-count
>keeps rising, even though the threads are exiting!!!!
>
>I read the MSDN, and it says that resources are automatically
>freed upon thread return from function.
>
>They also suggest that I call the endthreadex in order to make
>sure that I disallocated everything.
>
>How do they expect me the call it?!?!
>Do they want me to waitforsingleobject() on this thread?
>If they do - who should do this? ANOTHER THREAD!... and who should
>release the watchdog thread's handle? I will need a watchdog
>for every thread, since waitforsingleobjec is blocking...
>
>Anyway - I need help... any suggestions?
>
>
> thanks,
>
> - Barak
>
>--
>----------------------------------------------------
>Barak Mandelovich Mercury Interactive ltd.
>[email protected] 19 Shabazi st.
>Tel: +972 3 539 9286 Yehud, 56100
>Fax: +972 3 533 1617 Israel
>----------------------------------------------------
>