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 | [EMAIL PROTECTED] | OpenPGP: 0x991D8195
signature.asc
Description: OpenPGP digital signature
