PTHREAD_INVARIANTS in 5.x

[Scott Long]

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:
>>
>>#define MUTEX_INIT_LINK(m)              do {            \
>>         (m)->m_qe.tqe_prev = NULL;                      \
>>         (m)->m_qe.tqe_next = NULL;                      \
>>} while (0)
>>
>>I'm not sure what impact removing this explicit initialization would
>>have.  If we're not seeing fatal errors, everything else is just slowing
>>us down.  Assuming we feel our thread implementations are production
>>worthy, we should disable these checks for releases.  That is, unless I
>>am missing something...
> 
> 
> I wrote the darn things, and they are useful in that they can
> provide useful information if there are bugs and also for
> detecting if the application is linked to multiple thread
> libraries.  For the init links macro, it is only used when
> the mutex is initialized and on unlock.  It's two instructions.
> The others are also just a couple of instructions and shouldn't
> be called often.
> 
> 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 ;-)
> 
> That's the last I'll say.  re@ can do whatever they want
> with my blessing.
> 

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?

Scott