On Mon, May 19, 2003 at 11:31:51AM +0200, Ingo Molnar wrote:
> the solution to this problem is to not wake up the swarm of threads, but
> 'requeue' them from the CV-internal mutex to the user-supplied mutex. The
> attached patch adds the FUTEX_REQUEUE feature FUTEX_REQUEUE requeues N
> threads from futex address A to futex address B:
>
> sys_futex(uaddr, FUTEX_REQUEUE, nr_wake, NULL, uaddr2);
>
> the 'val' parameter to sys_futex (nr_wake) is the # of woken up threads.
> This way glibc can wake up a single thread (which will take the
> user-mutex), and can requeue the rest, with a single system-call.
Urgg, yet another sys_futex extension. Could you please split all
these totally different cases into separate syscalls instead?
> + wake_up_all(&this->waiters);
> + if (this->filp)
> + send_sigio(&this->filp->f_owner, this->fd, POLL_IN);
> + } else {
> + unpin_page(this->page);
> + __pin_page_atomic (page2);
> + list_add_tail(i, head2);
> + __attach_vcache(&this->vcache, uaddr2, current->mm, futex_vcache_callback);
Please linewrap after 80 lines, thanks.
> + case FUTEX_REQUEUE:
> + pos_in_page2 = uaddr2 % PAGE_SIZE;
> +
> + /* Must be "naturally" aligned */
> + if (pos_in_page2 % sizeof(u32))
> + return -EINVAL;
Who guarantess that the alignment of u32 is always the same as it's size?
-
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/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:33 EST