|
From: Jeremy F. <je...@go...> - 2002-10-29 20:52:05
|
I finally got around to implementing the thread lifetime segment (TLS) algorithm described in "Runtime Checking of Multithreaded Applications with Visual Threads". The results are interesting. For small test programs, the algorithm is clearly working, and it helps in reducing spurious warnings. For Mozilla it is also clearly working. This is an extract of the difference between early parts of the mozilla startup, showing a previously reported warning not being reported with TLS enabled because the location is changing ownership rather than changing state: Thread 2: -Possible data race writing variable at 0x43794CFC - at 0x403550A6: __pthread_mutex_destroy (vg_libpthread.c:965) - by 0x4033E5CD: PR_DestroyLock (in /usr/lib/libnspr4.so) - by 0x402D08A5: nsThread::WaitUntilReadyToStartMain(void) (in /usr/lib/libxpcom.so) - by 0x402D024D: nsThread::Main(void *) (in /usr/lib/libxpcom.so) - Previous state: exclusively owned by thread 1 - Address 0x43794CFC is 12 bytes inside a block of size 88 alloc'd by thread 1 at - at 0x4009D5ED: calloc (vg_clientfuncs.c:242) - by 0x40334662: PR_Calloc (in /usr/lib/libnspr4.so) - by 0x4033E58A: PR_NewLock (in /usr/lib/libnspr4.so) - by 0x402D063E: nsThread::Init(nsIRunnable *, unsigned int, PRThreadPriority, PRThreadScope, PRThreadState) (in /usr/lib/libxpcom.so) - Word at 0x43794CFC last accessed - at 0x40354E1C: __pthread_mutex_init+36 (vg_libpthread.c:882) - The counterintuitive result is that over the whole run, more errors are reported: -4265 possible data races found; 0 lock order problems +4335 possible data races found; 0 lock order problems I don't know if this is because there's fewer spurious errors and more real errors, or whether deferring some early spurious errors allows many more to appear later. J |
|
From: Julian S. <js...@ac...> - 2002-10-29 22:17:47
|
On Tuesday 29 October 2002 8:52 pm, Jeremy Fitzhardinge wrote: > I finally got around to implementing the thread lifetime segment (TLS) > algorithm described in "Runtime Checking of Multithreaded Applications > with Visual Threads". The results are interesting. > > For small test programs, the algorithm is clearly working, and it helps > in reducing spurious warnings. Great. > -4265 possible data races found; 0 lock order problems > +4335 possible data races found; 0 lock order problems > > I don't know if this is because there's fewer spurious errors and more > real errors, or whether deferring some early spurious errors allows many > more to appear later. Um, /me is pleased this is progressing, but I don't have any insights to add here. Sorry. J |
|
From: Jeremy F. <je...@go...> - 2002-10-29 22:36:56
|
On Tue, 2002-10-29 at 14:23, Julian Seward wrote: > Um, /me is pleased this is progressing, but I don't have any insights to > add here. Sorry. Oh well; I guess the thing to do is try it out on other things and see what happens. It's all ready for merging... J |