From owner-freebsd-hackers Tue Aug 14 6:35:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.spock.org (cm-24-29-85-81.nycap.rr.com [24.29.85.81]) by hub.freebsd.org (Postfix) with ESMTP id 4805C37B403 for ; Tue, 14 Aug 2001 06:35:25 -0700 (PDT) (envelope-from jon@enterprise.spock.org) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Tue, 14 Aug 2001 09:35:18 -0400 (EDT) (envelope-from jon)$ Date: Tue, 14 Aug 2001 09:35:18 -0400 From: Jonathan Chen To: "Daniel M. Eischen" Cc: hackers@freebsd.org Subject: Re: pthreads and poll() Message-ID: <20010814093518.A26202@enterprise.spock.org> References: <20010813120455.A63309@enterprise.spock.org> <3B780BFC.F2BA0A9B@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <3B780BFC.F2BA0A9B@vigrid.com>; from eischen@vigrid.com on Mon, Aug 13, 2001 at 01:18:52PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Aug 13, 2001 at 01:18:52PM -0400, Daniel M. Eischen wrote: > We don't provide locking for fd's any longer (I thought this was only in > -current, but your results seem to indicate otherwise). If we did, only > one thread would wake up. The mistake in your sample seems to be that > you're having all threads block on the same fd. Why? Consider a threaded server application, where N threads are blocking on M descriptors (M>>N). The test code is merely a simplified version of this scenario. I don't think this is a mistake, is it? > We took the approach in -current that it is up to the application to > provide locking for fd's. Our libc_r also wraps poll() into non-blocking > calls which allows the other threads to run and "block" on the same > fd. When we get blocking down in the kernel (KSEs or a linuxthreads > like approach), I'm not exactly sure what would happen. From your > results (linuxthreads under FreeBSD), it looks like it should behave > as you expect. Okay, I can understand why FreeBSD would do it this way, and why it might be a good thing to leave it up to the application to provide the locking. But on the flip side, it might be expensive to wake all the threads up when only one has any real work to do. I'm at a loss though, on how I could efficiently do locking so only one thread actually read() on the fd. If I create a mutex per fd, and lock it with one thread between poll() and read(), then other threads could do a blocking lock on the mutex, which would decrease the benefits of threading; or they could do non-blocking trylock's. In this case I could either make the thread continue to poll as before (which might starve the thread with the lock) or I can turn off polling on that fd (which might create a situation where a thread polls for no fd's and never again wakes up). I suppose I could be missing something incredibly simple, but where I stand right now I don't see a solution... Yes, I suppose I could just make the fd's non-blocking and catch the error on read(), but that's not too convenient and I was hoping for some other simple way to do this... Incidentally, I'm still curious, what does the POSIX spec say all this? -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message