This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pthread question for GDB?


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]