> On the other hand, Oliver needs to be careful about claiming too much. In > general atomic_t operations _are_ superior to the spinlock approach.
No they're not. Both are just about equally expensive cpu wise, sometimes the atomic_t ones are a bit more expensive (like on parisc architecture). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... > If > they weren't, atomic_t wouldn't belong in the kernel at all. there's different usage patterns where either makes sense. In this case it looks just disgusting on very first sight; the atomic are used to implement a lock, and that lock itself is then implemented with a spinlock again. For me, again on first sight, the real solution appears to be to use a linux primitive for the higher level lock in the first place, instead of reimplementing <your own thing> with <another own thing>. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
