Date: Thu, 12 May 2005 07:12:59 -0600 From: Scott Long <scottl@samsco.org> To: Daniel Eischen <deischen@freebsd.org> Cc: stable@freebsd.org Subject: Re: PTHREAD_INVARIANTS in 5.x Message-ID: <4283565B.6060303@samsco.org> In-Reply-To: <Pine.GSO.4.43.0505112240280.12550-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0505112240280.12550-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4283565B.6060303>