threads/141198: src/lib/libc/stdio does not properly initialize mutexes

Jeremy Huddleston jeremyhu at
Thu Jan 7 15:44:57 UTC 2010

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.

More information about the freebsd-threads mailing list