From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 17:38:05 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FF41065670; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66C3B8FC0A; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F269C46B29; Thu, 11 Feb 2010 12:38:04 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4FE0A8A01F; Thu, 11 Feb 2010 12:38:04 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 11 Feb 2010 12:36:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <201002110857.12206.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002111236.31975.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 12:38:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:38:05 -0000 On Thursday 11 February 2010 11:49:03 am Daniel Eischen wrote: > 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); > } I thought about doing something like this, but I think it is both kludgey and racy. It also doesn't fit in nearly as nicely as in Windows where the standard system objects can be used with WaitForMultipleObjects(). -- John Baldwin