Hi I removed the detachment of threads and join all threads at the end of my application. Now Helgrind says everything is ok - thanks!
Some questions though: In order to join all the threads, i collect them in a STL vector after their creation, and at the end of the program i do pthread_join for all threads in the vector. Is there a better way of doing that? I am worried that this way may be a resource eater: My server doesn't end for a long time - basically it runs in an eternal loop accepting new connections and creating new threads. Only when it is terminated manually does it reach the end of its code where join is called. What happens to all those threads who exited and are hoping to join? A similar scenario: assume the first thread lives for a long time, and all of the threads created later only live shortly. So all those dying threads would have to wait in line to be joined until the first thread is joined. Phrased differently: do threads which exited, but who weren't joined use up any resources? Is there perhaps something like the wait()-function which just handles the next thread waiting to join? Or something like a "join_all" where i would not need to keep track of the threads? Thank You Jody On Wed, Jan 28, 2009 at 10:18 PM, Rainer Gerhards <rgerha...@gmail.com> wrote: > I agree to these comments, but would also recommend to not *only* use > helgrind but also the new DRD tool. DRD did an excellent job for my > project. The newest release now contains a stable release. > > Just my 2cts... > > Rainer > > On Wed, Jan 28, 2009 at 6:44 PM, Julian Seward <jsew...@acm.org> wrote: >> >>> I have a server which creates a new detached pthread every time it >>> accepts a new connection. >> >> Hmm, detached threads are bad news, at least from a race detection >> point of view. See >> >> http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use >> point 5 ("Round up all finished threads using pthread_join. ..."). >> >> Try to pthread_join all your threads before the end of the program >> and see if that improves the situation. Maybe the lock you added >> isn't really necessary. >> >>> My question is: has there really been a data race, or did valgrind >>> only decide that if the timing is right, there could be a data race? >>> >>> >From the way i see it, there could not have been a real data race... >> >> But because your threads are detached, Helgrind cannot know when they >> finish (logically) relative to each other and the parent. That's why >> it is better to pthread_join to them. >> >> J >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Valgrind-users mailing list >> Valgrind-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
