Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Feb 2010 10:57:46 -0800
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        threads@freebsd.org
Subject:   Re: Thinking about kqueue's and pthread_cond_wait
Message-ID:  <20100210185746.GC71374@elvis.mu.org>
In-Reply-To: <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> <Pine.GSO.4.64.1002101331240.14115@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Daniel Eischen <deischen@freebsd.org> [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.

-- 
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100210185746.GC71374>