From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 2 20:53:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5240316A41F for ; Wed, 2 Nov 2005 20:53:01 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAA1C43D49 for ; Wed, 2 Nov 2005 20:53:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 02 Nov 2005 12:36:37 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43692355.1080003@elischer.org> Date: Wed, 02 Nov 2005 12:36:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> <43690EED.10703@elischer.org> <20051102.132709.101593999.imp@bsdimp.com> In-Reply-To: <20051102.132709.101593999.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 20:53:01 -0000 M. Warner Losh wrote: >In message: <43690EED.10703@elischer.org> > Julian Elischer 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. > >