From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 19:17:10 2010 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F213106566B; Wed, 10 Feb 2010 19:17:10 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 19DE68FC13; Wed, 10 Feb 2010 19:17:10 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 07D8B1A3D37; Wed, 10 Feb 2010 11:17:10 -0800 (PST) Date: Wed, 10 Feb 2010 11:17:09 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100210191709.GD71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:17:10 -0000 * Daniel Eischen [100210 11:06] wrote: > On Wed, 10 Feb 2010, Alfred Perlstein wrote: > > >* Daniel Eischen [100210 10:50] wrote: > >>On Wed, 10 Feb 2010, Randall Stewart wrote: > >> > >>> > >>> > >>>while (notdone) { > >>> nev = kevent(kq, , ev); > >>> if (ev.fitler == EVFILTER_READ) { > >>> handle_the_read_thingy(ev); > >>> } else if (ev.filter == EVFILTER_COND) { > >>> lock_mutex(if needed) > >>> handle_condition_event(); > >>> } > >>>} > >>> > >>> > >>>One of the things I will note about a condition variable is that the > >>>downside is > >>>you ALWAYS have to have a mutex.. and not always do you need one... I > >>>have > >>>found > >>>multiple times in user apps where i am creating a mutex only for the > >>>benefit of > >>>the pthread_cond() api... sometimes just being woken up is enough ;-) > >> > >>[ I didn't see that you were waiting on multiple CVs... ] > >> > >>I don't understand why you need to wait on multiple > >>condition variables. Either way, you have to maintain > >>a queue of them along with their associated mutexes and > >>then take some action unique to each one of them. What > >>is the difference between that and maintaining a queue of > >>some other thingies that maintain similar state data? > > > >Developer convenience. > > > >If we offer a stable API and way of doing it right, then we offer > >a solid base for programs. By making users roll their own we have > >them duplicate code and introduce errors, in fact the idea of how > >to get this working (using a pipe(2) loop back) is so esoteric to > >likely block a significant portion of users from solving this problem > >at all. > > See the proposed solution hacking the pthread API and think twice > about that. > > If you need a generic way of waiting and waking threads in kevent, > then extend the kqueue/kevent interface to allow it. Add a userland > struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to > send wake up that event. Again, this is not convenient. It is more complex and error prone for users. I will review the _additions_ to the pthreads API to see if they cause any performance issues for the "non-use" case. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer