Date: Thu, 11 Feb 2010 11:49:03 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: "threads@freebsd.org" <threads@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <Pine.GSO.4.64.1002111133550.18843@sea.ntplx.net> In-Reply-To: <201002110857.12206.jhb@freebsd.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Feb 2010, John Baldwin wrote:
> On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote:
>> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein <alfred@freebsd.org>
>> wrote:
>>
>>> * Daniel Eischen <deischen@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().
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002111133550.18843>