[lkml]   [2002]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores)
    Rusty Russell wrote:

    > In message <> you write:
    >>I can't see a reason why the ack-futex is needed. I think we can simply
    >>delete it.
    >>When deleted, the broadcast wouldn't block on ack (also preventing
    >>schedule ping-pong). With the cond->lock it's save to have several
    >>broadcasters. That's fine.
    > No, you might end up waking someone who did the pthread_cond_wait()
    > after you did the pthread_cond_broadcast in place of one of the
    > existing pthread_cond_wait() threads.
    > I don't believe this is allowed.

    Indeed, I suspect that this isn't wanted.
    With the cond->lock you almost prevent this: an ongoing broadcast
    can't be intermixed with newly incoming waiters (they will block
    on futex_down(&cond->lock))
    But there is the window between a->b...

    >>static int __pthread_cond_wait(pthread_cond_t *cond,
    >> pthread_mutex_t *mutex,
    >> const struct timespec *reltime)
    >> int ret;
    >> /* Increment first so broadcaster knows we are waiting. */
    >> futex_down(&cond->lock);
    >> atomic_inc(cond->num_waiting);
    >>(*) futex_up(&mutex, 1);
    >>a) futex_up(&cond->lock, 1); [move into syscall]
    >> do {
    >>b) ret = futex_down_time(&cond, ABSTIME); [cond_timed_wait]
    >> } while (ret < 0 && errno == EINTR);
    >> [futex_up(&cond->lock, 1); /* release condvar */]
    >> futex_down(&mutex->futex);
    >> return ret;
    >>With the original code, we have a "signal/broadcast lost window (a->b)"
    >>that shouldn't be there:
    > Where? Having done the inc, the futex_up at (a) will fall through,
    > giving the "thread behaves as if it [signal or broadcast] were issued
    > after the about-to-block thread has blocked."
    Right after (a) another thread gets scheduled, issueing a signal/broadcast.

    Ah, and then the futex_down_timed() wouldn't block, OK ;-)
    But this way you have to use the ack->lock

    I strongly believe, that the implementation of a condvar needs a lock
    to prevent intermixed calls. You will see my comment on your implementation
    with uwaitq. ;-)

    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:25    [W:0.024 / U:33.396 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site