From owner-freebsd-threads@FreeBSD.ORG  Wed Feb 10 18:49:16 2010
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
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 2AA9D1065692
	for <threads@freebsd.org>; Wed, 10 Feb 2010 18:49:16 +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 D89D88FC13
	for <threads@freebsd.org>; Wed, 10 Feb 2010 18:49:15 +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
	o1AIn488006729; Wed, 10 Feb 2010 13:49:04 -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]);
	Wed, 10 Feb 2010 13:49:04 -0500 (EST)
Date: Wed, 10 Feb 2010 13:49:04 -0500 (EST)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Randall Stewart <rrs@lakerest.net>
In-Reply-To: <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net>
Message-ID: <Pine.GSO.4.64.1002101331240.14115@sea.ntplx.net>
References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net>
	<Pine.GSO.4.64.1002101202060.13656@sea.ntplx.net>
	<3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net>
	<Pine.GSO.4.64.1002101232240.13876@sea.ntplx.net>
	<07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>, 
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 18:49:16 -0000

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?

-- 
DE