Maybe... gcc should also optimise my version to the same extent, I think (the
result of one of the additional tests is known at compile time, and the other
one is the same as the next test down). What I'm unsure about is how gcc will
handle the variable being stored in memory not marked volatile and then
retrieved again; whether it'll actually issue a read, or just assume it's got
it cached.
However, I've changed it to your suggestion, and I'm compiling it to have a
look. I've attached the changed C file for your perusal.
David
static inline struct rw_semaphore *__rwsem_do_wake(struct rw_semaphore *sem)
{
struct rwsem_waiter *waiter;
int woken;
rwsemtrace(sem,"Entering __rwsem_do_wake");
waiter = list_entry(sem->wait_list.next,struct rwsem_waiter,list);
/* if we are allowed to wake writers try to grant a single write lock if there's a
* writer at the front of the queue
* - we leave the 'waiting count' incremented to signify potential contention
*/
if (waiter->flags & RWSEM_WAITING_FOR_WRITE) {
if (!sem->activity) {
sem->activity = -1;
list_del(&waiter->list);
waiter->flags = 0;
wake_up_process(waiter->task);
}
goto out;
}
/* grant an infinite number of read locks to the readers at the front of the queue */
woken = 0;
while (waiter->flags&RWSEM_WAITING_FOR_READ) {
struct list_head *next = waiter->list.next;
list_del(&waiter->list);
waiter->flags = 0;
wake_up_process(waiter->task);
woken++;
if (list_empty(&sem->wait_list))
break;
waiter = list_entry(next,struct rwsem_waiter,list);
}
sem->activity += woken;
out:
rwsemtrace(sem,"Leaving __rwsem_do_wake");
return sem;
}
-
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/