From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:18:41 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 7D13D106568B; Wed, 10 Feb 2010 20:18:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 3013F8FC28; Wed, 10 Feb 2010 20:18:41 +0000 (UTC) Received: from mobile-166-129-159-005.mycingular.net (mobile-166-129-159-005.mycingular.net [166.129.159.5] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o1AKIWhb016646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 15:18:39 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: Alfred Perlstein In-Reply-To: <20100210200631.GE71374@elvis.mu.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Feb 2010 12:18:23 -0800 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> <20100210191709.GD71374@elvis.mu.org> <20100210200631.GE71374@elvis.mu.org> X-Mailer: Apple Mail (2.936) Cc: Daniel Eischen , 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 20:18:41 -0000 On Feb 10, 2010, at 12:06 PM, Alfred Perlstein wrote: > * Daniel Eischen [100210 12:01] wrote: >> On Wed, 10 Feb 2010, Alfred Perlstein wrote: >> >>> * 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 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. > Alfred: I have to say lead would only be in the *nix domain.. the windows world (dare I say that) has had the ability to mix things like condition variables and fd's for ages.. or at least so I have been told (I have never coded in windows)... But it would be nice to have a similar ability in FreeBSD.. but with DE so against it I will just find another way .. I guess what will happen is I will end up creating my own condition variable. I have never been a fan of the mutex tied to it... so I may not build that unless folks ask for it ;-) (I usually tend to be receptive to new features).... R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)