Date: Thu, 7 Jan 2010 10:44:54 -0500 From: Jeremy Huddleston <jeremyhu@apple.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/141198: src/lib/libc/stdio does not properly initialize mutexes Message-ID: <8C235DD0-74DA-4E15-A722-17772E8089DE@apple.com> In-Reply-To: <201001070956.25906.jhb@freebsd.org> References: <200912052034.nB5KYfaY000395@www.freebsd.org> <201001061600.47628.jhb@freebsd.org> <56AAD075-8202-40C0-AC75-18A5CDC3B76A@apple.com> <201001070956.25906.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Jan 7, 2010, at 09:56, John Baldwin wrote: >> vasprintf.c.patch:+ INITEXTRA(&f); >> vdprintf.c.patch:+ INITEXTRA(&f); >> vfprintf.c.patch:+ INITEXTRA(&fake); >> vfwprintf.c.patch:+ INITEXTRA(&fake); >> vsnprintf.c.patch:+ INITEXTRA(&f); >> vsprintf.c.patch:+ INITEXTRA(&f); >> vsscanf.c.patch:+ INITEXTRA(&f); >> vswprintf.c.patch:+ INITEXTRA(&f); >> vswscanf.c.patch:+ INITEXTRA(&f); > > Ah, ok. In our stdio at least these are all dummy files that are passed to > internal stdio routines that never do any locking (e.g. __vfprintf() which > does no locking vs vfprintf() which does use the mutex locks). I'm not sure > if that is also true for Darwin, but in theory it should be as these file > objects are all private stack variables that no other threads can gain a > reference to, so no locking is needed. Yeah, we're just being cautious with these changes. It takes one clock cycle and maintains the old (FBSD 7?) state of initializing the mutex during INITEXTRA in those dumies... just in case something gets added down the line which needs it. If you're confident that won't be the case for FBSD, then I believe your initial patch is sufficient.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C235DD0-74DA-4E15-A722-17772E8089DE>