Date: Wed, 11 May 2005 21:33:45 -0500 From: Jonathan Noack <noackjr@alumni.rice.edu> To: Daniel Eischen <deischen@freebsd.org> Cc: stable@freebsd.org Subject: Re: PTHREAD_INVARIANTS in 5.x Message-ID: <4282C089.4070806@alumni.rice.edu> In-Reply-To: <Pine.GSO.4.43.0505111053260.9248-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0505111053260.9248-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE5CE9286EB6F619E49D2149F
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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@alumni.rice.edu | OpenPGP: 0x991D8195
--------------enigE5CE9286EB6F619E49D2149F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQFCgsCOUFz01pkdgZURApLPAJ0SxqK5Zcdd5FVM62w0EVtI6yay4QCfWrMV
nhqV1HTAhnNkKvnE0vSW4Lw=
=sTrR
-----END PGP SIGNATURE-----
--------------enigE5CE9286EB6F619E49D2149F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4282C089.4070806>