Re: pthreads help needed to diagnose #98866
On Mon, May 28, 2001 at 04:11:35AM -0400, Matt Zimmerman wrote:
> On Mon, May 28, 2001 at 02:10:15AM -0500, Gordon Sadler wrote:
>
> > For your WORKS1 situation, I found it ran ps ux twice under the same PID and
> > 20 times under unique PIDs. I'm not sure this is what you want for threads?
>
> That's strange. For all of the #define situations, the output should look
> something like this:
>
> mizar:[~/src/mine/threadtest] ./threadtest
> mdz 17033 0.0 0.6 1992 828 pts/6 S 04:07 0:00 ./threadtest
> [pause here]
> mdz 17033 0.2 0.6 2000 864 pts/6 S 04:07 0:00 ./threadtest
> mdz 17038 0.2 0.6 2000 864 pts/6 S 04:07 0:00 ./threadtest
> mizar:[~/src/mine/threadtest]
>
> (for BROKEN, the memory usage after the pause will be much higher, e.g.:
>
> mizar:[~/src/mine/threadtest] !./
> ./threadtest
> mdz 17075 0.0 0.6 1992 828 pts/6 S 04:09 0:00 ./threadtest
> mdz 17075 0.2 0.7 42960 940 pts/6 S 04:09 0:00 ./threadtest
> mdz 17080 0.0 0.7 42960 940 pts/6 S 04:09 0:00 ./threadtest
> mizar:[~/src/mine/threadtest]
>
> )
>
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
> > The attached diff for your threadtest.cc, will cause it to run 22 times for
> > the same PID. From my understanding of the docs, you should implement
> > derived(Thread)::Run and call that, unless you need to 'specify the running
> > priority of a newly created thread relative to the "parent" thread which is
> > the thread that is executing when the constructor is called.'
>
> That's what ThreadTest is doing, deriving from Thread and implementing Run.
> That class's Run method happens to do nothing; it just exists to demonstrate
> the problem. What the example program does is spawn off a bunch of threads
> which just exit immediately.
>
> > - thread->Start();
> > + thread->Run();
>
> 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().
I'll look at it some more, but our expected outputs already differ -(.
--
Gordon Sadler
Reply to: