This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] Make fprintf() function to multithread-safe
On Tue, Jul 10, 2012 at 5:18 AM, Roland McGrath <roland@hack.frob.com> wrote:
> There is no need to target individuals in your email.
> Just post to the list.
>
> Please file a bugzilla report for this issue.
>
> I am not at all sanguine about taking any global locks in vfprintf,
> even a reader lock. It is a code path that is extremely common and
> often performance-critical. Conversely, register_printf_specifier
> et al are called very rarely and their performance never matters much.
>
> I think it's worth investigating an alternative approach where
> changes work by allocating a new table and replacing the old one
> with atomic operations. There is complexity there about tracking
> when it's safe to free the old table, so it's not a trivial change.
>
> Perhaps the reader locks are in fact just as efficient (for the
> reader) as anything that could be done with the atomic-supersede
> style. But I think it merits some real investigation and concrete
> performance analysis.
I agree with Roland here.
We need to see some real investigation and performance analysis.
Making fprintf multithread-safe is important, but we should not do
so using a heavy hammer approach involving global locks.
Do you have any workloads that you can use for performance testing?
Cheers,
Carlos.