Re: [PATCH] POSIX message queues - syscalls & SIGEV_THREAD

[Krzysztof Benedyczak <golbi@mat.uni.torun.pl>]

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