Rusty why not provide something along the line <snipped all over the place>.
#define FUTEX_DOWN (0)
#define FUTEX_UP (1)
#define FUTEX_FAIR_UP (2)
static int futex_up(struct list_head *head, atomic_t *count)
{
atomic_set(count, 1);
smp_wmb();
wake_one_waiter(head, count);
return 0;
}
static int futex_fair_up(truct list_head *head, atomic_t *count)
{
spin_lock(&futex_lock);
if (!pass_futex(head, count))
/* Noone to receive: set to one and leave it free. */
atomic_set(count, 1);
spin_unlock(&futex_lock);
return 0;
}
asmlinkage int sys_futex(void *uaddr, int op)
{
<..... snip ....>
head = hash_futex(page, pos_in_page);
switch (op) {
case FUTEX_DOWN:
ret = futex_down(head, page_address(page) + pos_in_page);
break;
case FUTEX_UP:
ret = futex_up(head, page_address(page) + pos_in_page);
break;
case FUTEX_FAIR_UP:
ret = futex_fair_up(head, page_address(page) + pos_in_page);
break;
default :
<..... snip ....>
}
This would satisfy the fair vs. calock issue, you let the app decide what to
use. Best of all, it seems to me you can even mix it.
Imagine, if a process knows it will soon reaquire the lock, then it would
use FUTEX_UP to avoid being tagged back to the end of wait queue
avoiding costly scheduling events. At the same time, if the process knows
that its done for a while with that lock, then it issues FUTEX_FAIR_UP.
The best of two worlds..
It also shows how cleanly the code can be expanded in the future.
The more I look at the hash queues the more I like it.
Will look at the rwlock now. Let me know what you think.
-- -- Hubertus Franke (frankeh@watson.ibm.com) - 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/