PTHREAD_INVARIANTS in 5.x

[Dan Nelson]

In the last episode (May 12), Scott Long said:
> Daniel Eischen wrote:
> >On Wed, 11 May 2005, Jonathan Noack wrote:
> >>I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
> >> As far as I can tell, all but one of the defines under
> >>_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
> >>is false result in a fatal error.  These should be very visible if
> >>they are being tripped.  Only MUTEX_INIT_LINK actually *does*
> >>something.  It is defined in src/lib/libpthread/thread/thr_mutex.c
> >>at lines 43-46 and in src/lib/libthr/thread/thr_mutex.c at lines
> >>44-47:
> >
> >This is way overblown and they're other areas for much better
> >optimizations than worrying about a couple of instructions.  Perhaps
> >if it were called _PTHREAD_ROBUST instead of _PTHREAD_INVARIANTS,
> >noone would notice ;-)
> 
> Yes, the check for the cross-linked threads libraries is still quite
> useful.  However, we gave a general policy of turning off most other
> debugging and invariants tools for production releases.  A good
> example is the malloc debugging options that are on in HEAD and off
> in RELENG_5. Would we be able to reach a compromise similar to that?

The malloc flags can cause serious performance issues, though, since
they basically force a memory fill before every malloc and after every
free.  On the other hand, shouldn't there be a better way of detecting
cross-linked threads libraries than dieing because some internal mutex
isn't initialized?  Maybe set __isthreaded to 1, 2, or 3 (or
(int)'c_r\0', 'kse\0', 'thr\0', to allow for even more threads libs)?

-- 
	Dan Nelson
	dnelson at allantgroup.com