Date: Fri, 6 Oct 2000 16:43:28 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Matthew N. Dodd" <winter@jurai.net> Cc: Mark Murray <mark@grondar.za>, Jake Burkholder <jburkhol@home.com>, Boris Popov <bp@butya.kz>, freebsd-smp@FreeBSD.ORG Subject: Re: Problems with kthread_exit() and SMPng Message-ID: <Pine.BSF.4.21.0010061628010.1977-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0010052152370.623-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Oct 2000, Matthew N. Dodd wrote: > On Thu, 5 Oct 2000, Mark Murray wrote: > > There is another problem; printf's inside a kthread corrupt like > > crazy. They look very unthreadsafe. > > I've been thinking about a buffered printf. Ugh. printf has to be unbuffered so that it can be used for debugging. Anyway, printf should work in all contexts, since ddb uses it (actually db_printf) and ddb may be invoked in any context (including at inconvenient points in any locking or buffering code that you may use in an attempt to avoid printfs at inconvenient points). I believe there is no problems except in console drivers. printf itself is reentrant. The serial console driver is fairly reentrant. The syscons driver has some old reentrancy problems (it doesn't even use spltty() for the main part of the i/o, and it does lots of non-atomic updates of critical variables). These have apparently become more serious. If the problem is just interleaved output due to threads interrupting each other, then the problem is not very serious (but allowing this interruption will probably trigger the syscons bugs). printf should probably run at a higher priority than the rest of the thread. Note that it shouldn't run at a much higher priority since the console output device may be slow. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010061628010.1977-100000>