Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


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/


WinNT handles problem using threads

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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
----------------------------------------------------

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    First let me start out by saying that the documentation surrounding
    _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
    >----------------------------------------------------
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online