[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pthreads help needed to diagnose #98866



On Mon, May 28, 2001 at 11:09:07AM -0500, Gordon Sadler wrote:

> Ok, I see what you are expecting now. However, it is reversed here. Your
> BROKEN causes output:
> gbsadler 24986  0.0  0.5  1824  724 tty3     S    11:00   0:00 ./threadtest
> gbsadler 24986  0.0  0.5  1832  756 tty3     S    11:00   0:00 ./threadtest
> gbsadler 24991  0.0  0.5  1832  756 tty3     S    11:00   0:00 ./threadtest
> 
> while WORKS1 produces:
> gbsadler 24941  0.0  0.5  1824  724 tty2     S    10:59   0:00 ./threadtest
> gbsadler 24941  0.1  0.6 40752  844 tty2     S    10:59   0:00 ./threadtest
> gbsadler 24946  0.0  0.6 40752  844 tty2     S    10:59   0:00 ./threadtest
> gbsadler 24948  0.0  0.6 40752  844 tty2     S    10:59   0:00 ./threadtest
> ...
> with increasing PIDs for a total of 22 items. The VSZ does not change on later PIDs

It sounds like ps is being run before all of the threads have exited.  Maybe
you should try increasing the sleep() at the end.  Are you commenting out
#define BROKEN when you #define WORKS1?

The problem is that even after the spawned threads have exited, virtual memory
usage remains at nearly the same level (about 40MB here also, or 2MB per
thread).  This is what happens if you create joinable threads and never join
with them, but should not happen with detached threads.

> > This will simply call the Run() method 20 times from the main thread, and
> > not create any threads at all.
> > 
> My understanding of the API was after a call to new (derived)Thread, a call
> to derived->Run() would create the thread.. the quote I gave above was given
> as the only reason to call derived->Start() as oppossed to Run().

The derived->Run() method contains the code to execute within the thread.  If
you look at thread.cpp, pthread_create is called with execHandler as the
function argument.  execHandler is a C wrapper that eventually calls
Thread::Run().  Since the thread cannot be started from the constructor for
portability reasons, it must be signaled to start after the constructor
completes.  Thread provides two ways to do this:

1. Use a semaphore.  The thread will be created as soon as the Thread-derived
   class is instantated, but it will block until the semaphore is posted.
   When a semaphore is used, Start() simply posts to the semaphore to let the
   thread continue.
2. Don't create the thread until after the constructor completes.  This is
   what happens if you pass NULL for the semaphore and then call Start.

-- 
 - mdz



Reply to: