[lkml]   [2003]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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?
    > >
    > 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:
    > 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".
    > 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.042 / U:13.376 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site