locking in a device driver

[Julian Elischer]

M. Warner Losh wrote:

>In message: <43690EED.10703 at elischer.org>
>            Julian Elischer <julian at elischer.org> writes:
>: Dinesh Nair wrote:
>: 
>: >
>: >
>: > On 10/28/05 10:52 M. Warner Losh said the following:
>: >
>: >> libc_r will block all other threads in the application while an ioctl
>: >> executes.  libpthread and libthr won't.  I've had several bugs at work
>: >
>: >
>: > so if the userland thread does an ioctl, and the the driver goes to 
>: > tsleep() when the ioctl is received, all other threads are also 
>: > blocked from executing, i.e wont be context switched to run ?
>: 
>: in 4.x and earlier. a tsleep saves your spl level but re-enables the 
>: interrupts (from memory)
>: when you re-awaken you are given your spl level again.. 
>
>That's true, but irrelevant.
>  
>

yes I misread the question.

>: All other threads are allowed to run.
>
>That is not true.[*] *NO* other threads in your process run.  Period.
>None.  Zero.  Nada.  Zilch.  Your process is hung until the ioctl
>returns.  That's the fundamental problem with userland thread packages
>such as libc_r.
>  
>

the answer is in the misread context and should have read,
"while your process is doingthe tsleep other processes can run"

I missed the bit about him talking about libc_r
and was thinking about only in the kernel.

>I've had to work around this issue many times, and I'm 100% certain
>that this is the case: sleep in an ioctl, and the entire process hangs
>until the ioctl returns.
>
>Warner
>
>[*] Other processes on the system will run, true.  Interrutps will
>happen and run.  But that's not what was being ask.
>  
>