From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 16:49:04 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 F14FB106566C; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91BE58FC1D; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1BGn3Bw007363; Thu, 11 Feb 2010 11:49:03 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 11 Feb 2010 11:49:03 -0500 (EST) Date: Thu, 11 Feb 2010 11:49:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201002110857.12206.jhb@freebsd.org> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "threads@freebsd.org" , freebsd-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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:49:05 -0000 On Thu, 11 Feb 2010, John Baldwin wrote: > On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: >> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein >> wrote: >> >>> * Daniel Eischen [100210 12:01] wrote: >>>> >>>> >>>> I strongly disagree. Using mutexes and condition variables in the >>>> proper way is not as easy as it sounds, let alone trying to mix >>>> them as userland thingies into kqueue. >>>> >>>> I will strongly oppose this... >>> >>> Well then you "win". I have no desire to engage in such discussion. >>> >>> I do hope that when you see this facility leveraged elsewhere for >>> an application that you reflect on this conversation and think back >>> on it the next time an opportunity presents itself to lead in >>> functionality. >> >> Don't misunderstand me, I just don't think running around the tree and >> adapting all the userland leaves to kqueue-isize them is the right >> approach. IMHO, it's better to extend the kqueue/kevent mechanism to >> allow a generic object to be added to the event list and the kqueue to >> be signaled from userland. All the pthread and semaphore functions >> are userland operations that also rely on userland structures anyway. > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on > this extensively. However, my point from my earlier post still stands and I > think it is the right way to implement something like NT's > WaitForMultipleObjects(). I guess that didn't exist in my 9.0-current that I looked at, so I replied privately with something very similar ;-) With this one could wrap pthread objects, semaphores, etc. The wrapper functions would have to additionally call kevent() to trigger the event if the object was being waited on in a kqueue, as in: typedef struct { #define MY_MTX_IN_KQUEUE 0x0001 int flags; pthread_mutex_t mutex; } my_pthread_mutex_t; my_pthread_mutex_unlock(my_pthread_mutex_t *m) { if (m->flags & MY_MTX_IN_KQUEUE) != 0) { /* Trigger the event. */ kevent(...); } ret = pthread_mutex_unlock(m->mutex); } -- DE