locking in a device driver
simon at comsys.ntu-kpi.kiev.ua
Thu Nov 3 05:26:15 PST 2005
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).
More information about the freebsd-hackers