From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 14:03:57 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 19DC1106566B; Thu, 11 Feb 2010 14:03:57 +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 DC5A38FC15; Thu, 11 Feb 2010 14:03:56 +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 7633046B2C; Thu, 11 Feb 2010 09:03:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 95EF08A021; Thu, 11 Feb 2010 09:03:55 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org, Daniel Eischen Date: Thu, 11 Feb 2010 08:54:59 -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> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002110854.59265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 09:03:55 -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: 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 14:03:57 -0000 On Wednesday 10 February 2010 12:46:46 pm Daniel Eischen wrote: > On Wed, 10 Feb 2010, Randall Stewart wrote: > > > > > On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: > > > >> On Wed, 10 Feb 2010, Randall Stewart wrote: > >> > >>> All: > >>> > >>> I have once again come around to thinking about joining pthread cond waits > >>> and > >>> kqueue's. > >>> > >>> After thinking about it, I think its doable.. with something like a: > >>> > >>> pthread_cond_wait_kqueue_np(kev, cond, mtx, ucontext) > >>> > >>> Then you can use kev inside a kqueue i.e. > >>> ret = kevent(kq, kev, 1, outkev, 1, NULL); > >>> > >>> Now when you saw the event: > >>> if (kev.filter == EVFILT_UMTX){ /* not sure about the name here */ > >>> pthread_kqueue_cond_wait_ret_np(kev, cond, mtx, ucontext) > >>> do_user_action(cond,mtx, ucontext); > >>> } > >>> > >>> Which would fill in the cond/mtx and ucontext for the user. > >>> > >>> Now does this sound useful to anyone.. i.e. should I spend the time > >>> making it work? > >>> > >>> The only down side to this is that it would have to allocate memory so > >>> one would need to do a: > >>> > >>> pthread_kqueue_cond_wait_free_np(kev) > >>> > >>> After you were done.. and I think it would be best for this to > >>> be a ONE_SHOT.. i.e. you have to re-arm it if the event happens... > >>> Of course until you free it that can be as simple as passing the kev > >>> back down again (i.e. no pthread_cond_wait_kqueue_np() needed). > >>> > >>> Comments? Thoughts? i.e. especially is it worthwhile doing? > >> > >> Please don't mess with the pthread_ API like that :-) If you > >> really want to munge them together, see my email to you a few > >> weeks ago last time you brought it up.' > > > > If I remember right your email was basically don't do it... I will > > go dig through the archives and re-read it all. > > No, it was to add an interface or two to the kqueue/kevent API, not > to modify the pthread_ API (which shouldn't know anything about > kqueues). > > I really think the OS is already given us the tools we need to > do the job simply enough. You can easily use a pipe, socketpair, > or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can > additionally use a mutex to protect data shared between thread > waiting in kevent() and other threads. > > I don't see what problem this is trying to solve and I think > whatever solution you come up with involving mutexes/CVs is > not going to be any simpler and may even be more complex and > messy. Mutexes and CVs are userland library thingies, not > kernel entities. Yes, the umtx is a kernel entity, but it > alone does not give you mutexes and CVs. So when you want > to mix kqueues and mutexes/CVs, you are involving another > userland library and this is what makes it messy. He wants something like 'WaitForMultipleObjects()' in NT. The fact that these are userland primitives is _precisely_ why I think it belongs in the pthread library. What I think is that you want a pthread primitive that is a wrapper around a kqueue. Something like: /* A lot like a 'struct event' */ struct pthread_event { }; /* Is actually an int to hold a kqueue fd. */ pthread_event_queue_t; /* Calls kqueue() to create the event. */ pthread_event_queue_init(); /* Similar to the kevent() call, but works with 'struct pthread_event' arrays instead of 'struct event' arrays. Internally, it maps 'struct pthread_event' objects to 'struct event' objects to pass to an internal call to kevent(). This code can take care of mapping requests to wait for a cv or mutex to the appropriate EVFILT_UMTX w/o exposing the EVFILT_UMTX implementation details to userland. */ pthread_event_queue_wait(); The user code model would look something like this: pthread_event_queue_t queue; struct pthread_event event; pthread_cond_t cv /* some condition variable */ int fd; /* some socket */ pthread_event_queue_init(&queue); /* This is like EV_SET, maybe you would have a EVQ_SET? */ event.filter = READ; event.fd = fd; event.flags = EV_ADD; /* Register socket. */ pthread_event_queue_wait(queue, NULL, 0, &event, 1, NULL); event.filter = CONDVAR; event.cv = cv; event.flags = EV_ADD; /* Register condvar. */ pthread_event_queue_wait(queue, NULL, 0, &event, 1, NULL); /* Wait for something to happen. */ for (;;) { pthread_event_queue_wait(queue, &event, 1, NULL, 0, NULL); switch (event.filter) { case READ: /* socket is ready to read */ case CV: /* cv is signalled */ } } To be honest, I find semaphores and mutexes more compelling than condvars for this sort of thing (you would do a try-lock to acquire the mutex or semaphore perhaps when it is signalled). If you supported thread objects you could do a pthread_join() after a thread exits. -- John Baldwin