Thinking about kqueue's and pthread_cond_wait
Alfred Perlstein
alfred at freebsd.org
Wed Feb 10 18:57:47 UTC 2010
* Daniel Eischen <deischen at 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
More information about the freebsd-threads
mailing list