From: Kyle Moffett <[email protected]>
Date: Sun, 16 Jul 2006 08:34:53 -0400
> Both of which may be easily cut and pasted into your GPL programs
> with little or no effort (Hint: I do this all the time). Those are
> so stable you don't even have to maintain it! IMHO, what you really
> want, though, is for GCC to export a library of ASM intrinsics (like
> memory barriers, atomic ops, etc), that are available on your current
> architecture. If there is no __gcc_atomic_inc then it wouldn't
> #define it and you can just go back to pthread_mutex_lock/unlock for
> protecting an atomic variable. Such a library layer certainly
> doesn't belong in the kernel, although if GCC got such a library
> right the kernel might start to use it (although only the most recent
> GCC would support it so it wouldn't be very useful).
I agree with your assertions that the stuff in asm/atomic.h should be
steered away from, since they generally are not expected to work in
userspace. In fact, if you try to use the 32-bit sparc or parisc
ones, it simply won't link because the implementations are external
and use a hash table spinlock scheme which is in the kernel image.
However, the pthread based locking is bad if you want to recover
from arbitrary signals correctly. I ran into this problem while
trying to get Linux/Sparc Mono working well.
When people want atomic cmpxchg or atomic increment/decrement, they
want a true atomic. This means either finish the whole thing, or
leave no trace of the atomic having started in the first place.
Spinlock based atomic implementations, which is what a lot of
platforms lacking true atomic use, absolutely cannot reasonably
provide this semantic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
