On Tue, 6 Dec 2005, Oliver Neukum wrote: > Am Dienstag, 6. Dezember 2005 21:13 schrieb Eduardo Pereira Habkost: > > Anyway, I don't see yet why the atomic_t would make the code slower on > > non-smp. Is atomic_add_unless(v, 1, 1) supposed to be slower than > > 'if (!v) v = 1;' ? > > spin_lock() can be dropped on UP. atomic_XXX must either use an operation > on main memory, meaning less efficient code generation, or must disable > interrupts even on UP.
atomic_add_unless is sort of a special case. It doesn't have a clean simple implementation, unlike most of the other atomic_t operations. If an equivalent result could be obtained using, e.g., atomic_inc_and_test, that would be a better approach. On the other hand, Oliver needs to be careful about claiming too much. In general atomic_t operations _are_ superior to the spinlock approach. If they weren't, atomic_t wouldn't belong in the kernel at all. Alan Stern ------------------------------------------------------- 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
