Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 18 Nov 2003 13:20:49 +0100 (CET) | From | Krzysztof Benedyczak <> | Subject | Re: [PATCH] POSIX message queues - syscalls & SIGEV_THREAD |
| |
On Mon, 17 Nov 2003, Jamie Lokier wrote:
> Krzysztof Benedyczak wrote: > > > Please can you describe your "intuitive solution" using FUTEX_FD more clearly? > > [cut] > > To be honest I don't understand the purpose of this manager thread, > but then I know very little about POSIX message queues.
Oh, I it think it doesn't matter much anyway...
> > > > I don't quite understand what you wrote, but there are flaws(*) in the > > > current FUTEX_FD implementation which I would like to fix anyway. > > > > Now I'm not sure if we are talking about the same flaw. In our case: the > > problem is that after returning from poll we do some work (create thread > > etc.) and after a while we return to poll(). If some notification will > > occur then - ups we will miss it. > > You said something about cancellation, is this the same thing?
I'm afraid not ;-). In our case there can happen two situations after setting notification: 1) (normal) notification event that have to be serviced 2) cancellation of notification - when thread which some time ago set notification resigns from it. In general it is only important that we need a possibility to "signal" userspace with 2 different values.
> > > Perhaps we can improve async futexes in a way which is useful for you? > > > > Maybe something like poll which would have just one difference. It would > > have to check if all of futexes given as parameter have the same value as > > given parameters. If not - it should return immediately with EWOULDBLOCK. > > In another words some hybrid of poll and FUTEX_WAIT. Or even simplier: > > MULTIPLE_FUTEX_WAIT. > > You don't need any futex change. You can do this already in userspace on top > of FUTEX_FD: > > 1. In userspace, check all the futexes against the values. > 2. If any are different, return "did not sleep". > > 1. and 2. are just an optimisation; if that case is rare, they aren't needed. > > 3. Call FUTEX_FD for each futex and store the fds. > 4. Check all the futexes against the values. > 5. If any are different, close() the fds and return "did not sleep". ------>hole > 6. Call poll() on the list of fds to wait until one becomes ready. > 7. close() the fds and return "woken". > > Note that this is not necessarily the most efficient implementation > for your purpose, but it would work. > > There is a problem if you depend on the "token passing" property of > futexes to keep track of the exact number of wakeups: between poll() > and close() you may lose wakeups which a waker thinks it sent. This > is because async futex "test and remove" is not atomic if the test > says there was no wakeup, unlike sync futex. This is the flaw I would > like to fix for async futexes, but it is not necessarily relevant to > your problem.
If I understand you in the right way - yes it is important. The very simple situation - we have two futexes. One wakeup on first futex happen between 5. and 6. On the futex number 2 never. Or after an hour.
Thanks, Krzysiek
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |