Date: Wed, 10 Feb 2010 12:32:03 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <Pine.GSO.4.64.1002101227440.13876@sea.ntplx.net> In-Reply-To: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> <Pine.GSO.4.64.1002101146300.13656@sea.ntplx.net> <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Feb 2010, Randall Stewart wrote: > > On Feb 10, 2010, at 8:59 AM, Daniel Eischen wrote: > >> On Wed, 10 Feb 2010, Randall Stewart wrote: >> >>> Alfred: >>> >>> Basically I would like to have a dispatch/reactor loop that can >>> wait on multiple events. Including a condition variable that might >>> be in shared memory or for that matter some other thread awakening >>> it to do something without having to create a pipe and write/read >>> a byte. >>> >>> A peer process could also "wake" the condition variable and this >>> would then show up as an event in my dispatch loop, assuming the cond >>> variable and mutex are in shared memory that is... For example a >>> peer could plop some data in shared memory (via a shm queue or >>> some such other construct) and then do a cond_wake() and ta-da >>> coolness ;-) >> >> Is it really that much different than creating a pipe and >> adding it to the kevent list? It seems pretty straight forward >> to use a pipe rather than munge condition variables and mutexes >> into kqueue. Plus, we don't even support (yet) mutexes and >> condition variables in shared memory, and if we did, this >> solution wouldn't be too portable across different FreeBSD >> releases. >> > > > Hmm I thought someone said in 9 we are supporting shared memory > pthreads... which I was hopeful for.. since that would avoid > internal hacks.. So far only semaphores, but I believe David is working on mutexes and condition variables. But either way, that would only be a solution for 9. >> Whether you are using pthread_cond_signal() or write()'ing >> a byte to the special pipe, you are still calling in to the >> kernel to wake another thread stuck in kevent(). You could >> also send a signal to the thread stuck in kevent() if you >> wanted to wake it up (EVFILT_SIGNAL). > > But these are different things.. So are mutexes. But they can achieve what you want to achieve. All you want to do is wakeup a thread stuck in kevent(). Munging the pthread_ API is not a unified approach, IMHO. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002101227440.13876>