Pthread question for GDB?

Pthread question for GDB?

[Jan Chludzinski]

If I'm stepping through main() in GDB, when I step past
pthread_create() should the associated (newly created) thread begin
executing independently of main() (i.e., the "main" thread)?
Executing independently in the background?

Red Hat's GDB documentation says: "In all-stop mode, whenever your
program stops under gdb for any reason, all threads of execution stop,
not just the current thread. This allows you to examine the overall
state of the program, including switching between threads, without
worrying that things may change underfoot. "

I assume "all-stop mode" is the default?

---Jan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread question for GDB?

[Ryan Johnson]

On 14/07/2011 5:43 AM, Jan Chludzinski wrote:
> If I'm stepping through main() in GDB, when I step past
> pthread_create() should the associated (newly created) thread begin
> executing independently of main() (i.e., the "main" thread)?
> Executing independently in the background?
Welcome to the jungle.

This has everything to do with the beast called parallelism and nothing 
to do with either cygwin or gdb (which is probably why you're not 
getting replies).

A short-running thread can easily complete before pthread_create returns.

Here's the law of the jungle, as simply put as I know: other threads can 
and will do *anything* they want, performing an arbitrary amount of 
work, in the time it takes the thread you're watching to execute a 
single machine instruction. Every time you assume otherwise you *will* 
be disappointed. This applies whether you're single stepping in gdb or not.

The only way around the above is to explicitly make threads wait for 
each other (which can easily slow your program down enough that it may 
as well be single-threaded). Go read up on races, critical sections, 
mutex locks, condition variables, semaphores, etc.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Pthread question for GDB?

[Jan Chludzinski]

> This has everything to do with the beast called parallelism and nothing to do with either
> cygwin or gdb (which is probably why you're not getting replies).
>
> A short-running thread can easily complete before pthread_create returns.
>
> Here's the law of the jungle, as simply put as I know: other threads can and will do
> *anything* they want, performing an arbitrary amount of work, in the time it > takes
> the thread you're watching to execute a single machine instruction. Every time you
> assume otherwise you *will* be disappointed.
>
> This applies whether you're single stepping in gdb or not.

I've debugged pthreads before using GDB on Linux and Unix but GDB
seemed to abide by:
"whenever your program stops under gdb for any reason, all threads of
execution stop, not just the current thread. This allows you to
examine the overall state of the program, including switching
between threads, without worrying that things
change underfoot." (GDB manual)

I've used condition variables before to create pthreads that are born
sleeping (i.e., waiting for a condition variable to be signaled) but
(under Linux and Unix) I've never had this problem of a thread
finishing before I could even switch to it and start stepping.

BTW, when there's different behavior between GDB (or any GNU dev tool)
under Cygwin and Unix/Linux, I do believe that it's appropriate to
post a question concerning this on the cygwin mailing list.

---Jan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple