Hi,
> Here's the RW semaphore patch #3. This time with more asm constraints added.
Personally I care about sparc and ppc64 and as such would like to see the
slow paths end up in lib/rwsem.c protected by #ifndef __HAVE_ARCH_RWSEM
or something like that. If we couldn't get rwsems to work on x86, what
hope have we on other archs? :)
I have a few questions:
In arch/i386/kernel/semaphore.c:
static inline int rwsem_atomic_update(int delta, struct rw_semaphore *sem)
static inline __u16 rwsem_cmpxchgw(struct rw_semaphore *sem, __u16 old, __u16 new)
Can these end up in include/asm/rwsem*? The rest could then go into
lib/rwsem.c.
/* try to grab an 'activity' marker
* - need to make sure two copies of rwsem_wake() don't do this for two separate processes
* simultaneously
* - be horribly naughty, and only deal with the LSW of the atomic counter
*/
if (rwsem_cmpxchgw(sem,0,RWSEM_ACTIVE_BIAS)!=0)
Many archs dont have cmpxchg on 16 bit quantities. We can implement it
but it will be extra instructions. Anyway on 64 bit archs, count will be
64 bit so we will have two 32 bit quantities to cmpxchg on.
Now that I look at it, can you just do a cmpxchg on the complete sem->count
and retry if it failed because the high order bits have changed?
Anton
-
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 : Sun Apr 15 2001 - 21:00:17 EST