Re: Thinking about kqueue's and pthread_cond_wait
John Baldwin
> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein <alf...@freebsd.org>
> wrote:
>
> > * Daniel Eischen <deis...@freebsd.org> [100210 12:01] wrote:
> >>
> >>
> >> 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.
>
> Don't misunderstand me, I just don't think running around the tree and
> adapting all the userland leaves to kqueue-isize them is the right
> approach. IMHO, it's better to extend the kqueue/kevent mechanism to
> allow a generic object to be added to the event list and the kqueue to
> be signaled from userland. All the pthread and semaphore functions
> are userland operations that also rely on userland structures anyway.
kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on
this extensively. However, my point from my earlier post still stands and I
think it is the right way to implement something like NT's
WaitForMultipleObjects().
--
John Baldwin
John Baldwin
> 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
Randall Stewart
On Feb 11, 2010, at 5:57 AM, John Baldwin wrote:
>>
>
> kqueue/kevent already support that via EVFILT_USER, and Apple's GCD
> depends on
> this extensively. However, my point from my earlier post still
> stands and I
> think it is the right way to implement something like NT's
> WaitForMultipleObjects().
>
> --
> John Baldwin
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threa...@freebsd.org
> "
>
John:
Is this being MFC'd to 8?
I have an 8.0 machine at work where I am doing a lot of this userland
stuff.. and the
EVFILT_USER is not present but precisely what I need.
R
------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
John Baldwin
>
> On Feb 11, 2010, at 5:57 AM, John Baldwin wrote:
>
> >>
> >
> > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD
> > depends on
> > this extensively. However, my point from my earlier post still
> > stands and I
> > think it is the right way to implement something like NT's
> > WaitForMultipleObjects().
> >
> > --
> > John Baldwin
> > _______________________________________________
> > freebsd...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> > To unsubscribe, send any mail to "freebsd-threa...@freebsd.org
> > "
> >
>
>
> John:
>
> Is this being MFC'd to 8?
>
> I have an 8.0 machine at work where I am doing a lot of this userland
> stuff.. and the
> EVFILT_USER is not present but precisely what I need.
It is in stable/8 I thought, just not 8.0 release.
--
John Baldwin
Daniel Eischen
I guess that didn't exist in my 9.0-current that I looked at, so
I replied privately with something very similar ;-) With this
one could wrap pthread objects, semaphores, etc. The wrapper
functions would have to additionally call kevent() to trigger
the event if the object was being waited on in a kqueue, as in:
typedef struct {
#define MY_MTX_IN_KQUEUE 0x0001
int flags;
pthread_mutex_t mutex;
} my_pthread_mutex_t;
my_pthread_mutex_unlock(my_pthread_mutex_t *m)
{
if (m->flags & MY_MTX_IN_KQUEUE) != 0) {
/* Trigger the event. */
kevent(...);
}
ret = pthread_mutex_unlock(m->mutex);
}
--
DE
John Baldwin
I thought about doing something like this, but I think it is both kludgey and
racy. It also doesn't fit in nearly as nicely as in Windows where the
standard system objects can be used with WaitForMultipleObjects().
--
John Baldwin