Hi Holger,
This is a very interesting question. I don't have any good answers, so I am
looking forward to seeing if anyone else on the list has any good
methodologies or even small hints and tips they can suggest.
I could stand up on my soap box here and give my long speech on threading
architectures ... but I'll spare everyone. :-)
The summary though is that threaded architectures add complexity and can
create timing bugs or order dependent bugs. The end result can be a system
that works most of the time, and then randomly crashes for no apparent
reason. Often it can take hours (if not days or weeks) of running the code
to tickle the bug ... and most of the time you have to trigger the bug to
see what happened and get any kind of idea where it happened so you can fix
it. Also, even with a perfectly written threaded system, it's easy to come
back in 6 months and forget something about the design and make a change
that introduces a subtle problem. This is even more likely if someone else
comes later and touches the code without having ever understood all the
nuances (sequence, and timing, etc.) of how all the threads work together.
Personally I try to avoid threads whenever possible, and only use them when
there is no sane alternative solution. But I understand that threads are a
fact of life so they can't always be avoided.
When I've had to debug threaded code I've used a mix of gdb (and compiling
everything with full debugging symbols) to get a back trace if there is a
crash. I also like to use printf's to see the sequence or progress of the
code as it runs. If I get desperate I might haul out valgrind and see if
that offers any clues. I've also spent hours just staring at the code and
mentally working through the sequencing of the threads and the
locking/mutual-exclusion primatives trying to analyze it all in my head and
look for "logic" bugs that way. All of this is pretty tedious, un-fun
stuff.
Maybe someone else has other tips and tricks. I don't think I've run across
any higher level methodologies that you can work through to always sniff out
any threading bug.
I know other people may feel differently about the use of threads and their
relative benefits and dangers ... and that's fine. I like to think of
threads like nun-chucks. I'll probably get moved over to the soprano
section of the choir before I manage to do anything useful too spectacular
with them. :-)
Curt.
On Mon, Mar 21, 2011 at 9:04 AM, Holger Wirtz wrote:
> Hi all,
>
> sorry - a little bit off-topic (in fact not so much as you might think,
> it's for a third-party software for FG):
>
> Has anyone some hints/websites/programs for debugging C -based multi
> threaded programs (exactly: glib based C code)? Currently I am
> developing with vi and a little bit gdb (command line) and very much
> debug output. But this setup seems to be very frustrating while
> searching for dead-locks and race-conditions :-(
>
> On the other hand I won't invest too much time for studying rocket
> engeneering only to use framework XYZ. Has anyone some ideas how to
> debug with less effort?
>
> Thanks, Holger
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
