Date: Thu, 3 Nov 2005 15:25:00 +0200 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Dinesh Nair <dinesh@alphaque.com> Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver Message-ID: <20051103132500.GA73085@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <436927AE.4030809@alphaque.com> References: <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> <43690EED.10703@elischer.org> <20051102.132709.101593999.imp@bsdimp.com> <436927AE.4030809@alphaque.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 03, 2005 at 04:55:10AM +0800, Dinesh Nair wrote: > > On 11/03/05 04:27 M. Warner Losh said the following: > >that this is the case: sleep in an ioctl, and the entire process hangs > >until the ioctl returns. > > which is probably what's happening in my case. i've got 4 threads spun off, > and one thread reads what the other writes and vice versa. after writing, a > thread goes off into an ioctl or a read where a tsleep() is executed. this > would block the reader thread as well if libc_r were to be used, as is what > i am using. Having read all messages (really interesting) in this thread, I decided to add some words. Multi threaded application which uses user level thread library always will have problems if used user level thread library is not aware about some function which can block in the kernel. According to my understanding... Blocking operations on file descriptors internally in user level thread library are converted to non-blocking and library periodically checks for events on such descriptors (at least before switching to another userland thread, somewhere in signal handler (user level scheduler), which is used in the same style as hardware clock). And application does not need to do anything to convert all blocking syscalls to non-blocking versions. Since implementation of ioctl() (own device's part), is unknown to the library (really it is unknown also for the kernel) it is impossible to say from the userland if this system call is blocking or not. As I remember, SysV semaphores had the same problem in <4.x (but it seems that it is possible to fix this problem, again nonblocking variant with periodic checks). The same problem with custom syscalls (they like custom ioctls).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051103132500.GA73085>