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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
