Comments on: Finding Thread-unsafe Code http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/ Linux, politics, and other interesting things Thu, 09 Feb 2012 01:09:24 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: etbe http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19550 etbe Tue, 16 Jun 2009 13:18:45 +0000 http://etbe.coker.com.au/?p=1200#comment-19550 foo and Nick: Thanks for the suggestion, I'm investigating that now. Chris: That's interesting for HPC, but not of much use for what I'm doing. I have to work with the standard Milter libraries which don't support such things. Bill: Good point, that's one of the many rough edges in my code. I trimmed the OTHERS list, it's the entries from Sun's list that didn't appear when I searched the man pages - mostly functions with no reentrant versions. Your idea is much better. foo and Nick: Thanks for the suggestion, I’m investigating that now.

Chris: That’s interesting for HPC, but not of much use for what I’m doing. I have to work with the standard Milter libraries which don’t support such things.

Bill: Good point, that’s one of the many rough edges in my code. I trimmed the OTHERS list, it’s the entries from Sun’s list that didn’t appear when I searched the man pages – mostly functions with no reentrant versions. Your idea is much better.

]]> By: Bill Farrow http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19542 Bill Farrow Mon, 15 Jun 2009 19:30:54 +0000 http://etbe.coker.com.au/?p=1200#comment-19542 On my system I needed to remove the duplicate functions names before compiling the library. Added "sort -u" to the code. Actually you might want merge the $OTHERS into the list before sorting and removing duplicates. - for n in $OTHERS $(ls -1 /usr/share/man/man3/*_r.*|sed -e "s/^.*\///" -e "s/_r\..*$//"|grep -v ^lgamma) ; do + for n in $OTHERS $(ls -1 /usr/share/man/man3/*_r.*|sed -e "s/^.*\///" -e "s/_r\..*$//"|grep -v ^lgamma | sort -u) ; do On my system I needed to remove the duplicate functions names before compiling the library. Added “sort -u” to the code. Actually you might want merge the $OTHERS into the list before sorting and removing duplicates.

- for n in $OTHERS $(ls -1 /usr/share/man/man3/*_r.*|sed -e “s/^.*\///” -e “s/_r\..*$//”|grep -v ^lgamma) ; do
+ for n in $OTHERS $(ls -1 /usr/share/man/man3/*_r.*|sed -e “s/^.*\///” -e “s/_r\..*$//”|grep -v ^lgamma | sort -u) ; do

]]> By: Chris Samuel http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19529 Chris Samuel Sun, 14 Jun 2009 11:49:12 +0000 http://etbe.coker.com.au/?p=1200#comment-19529 I'd take issue with the statement that non-threaded programs can't take advantage of CPUs and are slower than threaded ones. :-) Many HPC codes are non-threaded MPI programs, they take full advantage of multiple cores. In fact we've seen one particular code available in both a threaded SMP version and a pure MPI version and found that the MPI version makes far more efficient use of an SMP system (scales better) than the SMP version. Regarding threading being faster, Tridge has already <a href="http://lists.samba.org/archive/samba-technical/2004-December/038301.html" rel="nofollow">made a convincing case back in 2004</a> (mentioned in passing at a LUV meeting way back when it was in the Telstra building) that threads are always slower than processes, asides from when the OS is very broken. I’d take issue with the statement that non-threaded programs can’t take advantage of CPUs and are slower than threaded ones. :-)

Many HPC codes are non-threaded MPI programs, they take full advantage of multiple cores. In fact we’ve seen one particular code available in both a threaded SMP version and a pure MPI version and found that the MPI version makes far more efficient use of an SMP system (scales better) than the SMP version.

Regarding threading being faster, Tridge has already made a convincing case back in 2004 (mentioned in passing at a LUV meeting way back when it was in the Telstra building) that threads are always slower than processes, asides from when the OS is very broken.

]]> By: Nick http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19528 Nick Sun, 14 Jun 2009 07:20:02 +0000 http://etbe.coker.com.au/?p=1200#comment-19528 Some related work: Helgrind is a thread debugger which finds data races in multithreaded programs http://valgrind.org/info/tools.html Nick Nethercote has done some additional work on looking for non reentrant functions called by signal handlers: http://valgrind.org/downloads/variants.html?njn Some related work:

Helgrind is a thread debugger which finds data races in multithreaded programs
http://valgrind.org/info/tools.html

Nick Nethercote has done some additional work on looking for non reentrant functions called by signal handlers:
http://valgrind.org/downloads/variants.html?njn

]]> By: foo http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19527 foo Sun, 14 Jun 2009 07:04:05 +0000 http://etbe.coker.com.au/?p=1200#comment-19527 Does helgrind help? http://valgrind.org/docs/manual/hg-manual.html Does helgrind help?

http://valgrind.org/docs/manual/hg-manual.html

]]> By: etbe http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/comment-page-1/#comment-19526 etbe Sun, 14 Jun 2009 06:15:57 +0000 http://etbe.coker.com.au/?p=1200#comment-19526 glandium: Good point. But then you need to grep the output for the functions in question, you have the ptrace overhead, and when it does flag a problem you won't know the back-trace of it. glandium: Good point. But then you need to grep the output for the functions in question, you have the ptrace overhead, and when it does flag a problem you won’t know the back-trace of it.

]]>