Re: Locks and threads

2009-02-12 Thread Ken Raeburn

On Feb 12, 2009, at 07:55, Greg Troxel wrote:

 Does that sound sensible; have I missed anything?

Also run tests on other than Linux, with as many different OS  
threading

implementations as possible.  For all systems, set the threading
libraries to the most restrictive settings, specifically aborting on  
any

behavior the standard says is undefined.


Yeah, definitely NetBSD is a good one for this.


If the define-race program gets added as a check that make check runs,
my autobuild machine will run it daily.

I am not familiar with helgrind; not sure if it's useful to run that  
on

other platforms once it's ok on one, or what platforms it runs on.


It's part of the valgrind suite, which currently only runs on Linux,  
though there is porting work in progress.  The helgrind tool checks  
for possible synchronization issues.


As helgrind and NetBSD's pthread checking code work by instrumenting  
the executable and watching progress, I'd suggest also trying out  
static analysis tools if anyone has them handy.  I see guile is  
already listed with Coverity's open-source scanner project; who's  
reviewing that data, if anyone?


Ken




Re: Locks and threads

2009-02-12 Thread Ludovic Courtès
Hello,

Neil Jerram n...@ossau.uklinux.net writes:

 (Is something like this actually _ever_ a problem?  If locks are
 always _acquired_ in the right order, how can the order of _releasing_
 ever cause a problem?)

It can't be a problem, AFAIUI.  I don't think Helgrind check the
releasing order, though; the manual doesn't mention it
(http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders).

Thanks,
Ludo'.





Re: Locks and threads

2009-02-12 Thread Ludovic Courtès
Hello,

Ken Raeburn raeb...@raeburn.org writes:

 As helgrind and NetBSD's pthread checking code work by instrumenting
 the executable and watching progress, I'd suggest also trying out
 static analysis tools if anyone has them handy.  I see guile is
 already listed with Coverity's open-source scanner project; who's
 reviewing that data, if anyone?

I don't feel like supporting that tool.  I noticed that other free
software supporters are doubtful, too:
http://blog.josefsson.org/2007/04/02/boycott-scancoveritycom/ .

We could use tools like Splint, but it seems to be quite intrusive and
difficult to use when not used from the beginning of the project (to get
an idea it gives 97 warnings on `alist.c'...).

Thanks,
Ludo'.