PTHREAD_INVARIANTS in 5.x

[Jonathan Noack]

On 05/11/05 09:55, Daniel Eischen wrote:
> On Tue, 10 May 2005, Mikhail Teterin wrote:
>>= > As we were counting down to 5.3-RELEASE, I noticed, that all
>>= > threading libraries still compile with PTHREAD_INVARIANTS. My
>>= > suggestion to have this = > fixed was shutdown as not enough time
>>= > was left for testing the 5.3.
>>
>>= > Can we have these things turned off NOW, so that, at least, 5.5
>>= > stands a chance? Thanks!
>>=
>>= What makes you think there is a measurable performance impact with
>>= them on?
>>
>>Interesting... Are you implying, the debugging code makes no difference,
>>or are genuinly asking?
> 
> Both.
> 
>>There are additional steps in the code, that are only done when
>>the define is on. Does not look like much in libthr, but c_r's
>>uthread/uthread_mutex.c seems quite affected, for example. And you know
>>it, of course...
> 
> c_r is deprecated, so I've no interest in that.  My only concern
> is with libthr and libpthread.

I agree.

>>= Regardless, it would first need to be in -current, not -stable.
>>
>>I thought, the debugging features (WITNESS INVARIANTS) are always on in
>>-current, but are turned off in -stable for maximum performance. Is that
>>no longer true?
> 
> They've never been off in -current.  You'd have to show turning
> them off causes no harm.

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...

Anyone know any good thread tests to run to determine what performance 
impact this is having?

-- 
Jonathan Noack | noackjr at alumni.rice.edu | OpenPGP: 0x991D8195
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050511/cfb1d7a1/signature.bin