Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.

[linux-os (Dick Johnson)]

On Wed, 7 Dec 2005, Alan Stern wrote:

> 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

You need to know what it is that you intend to do if the code
encounters a locked section.

For example, let's pretend that every operation is atomic so
that only the logic is investigated...

 	if(!critical_section_flag) {
             critical_section_flag = TRUE;
             do_something_in_critical_section();
         }
         else
             WTF?;


A spin-lock will prevent the current CPU from even getting to
or modifying data in the critical section because alternate paths
via interrupts are blocked. The only other way for data to be
modified is from another CPU. That CPU will spin until the current
CPU releases the lock.

Atomic operations on flags (semaphores) provide the opportunity
for another CPU to do something useful until the critical section
is released, the WTF above. However, if the other CPU can't
schedule you are caught between a rock and a hard-place because
you would need to spin anyway.

Basically, if you can schedule, it's much better to protect
a section with semaphores and do the down(&semi) / up(&semi) thing.
If you can't schedule, it's much cleaner to use a spin-lock
which, in fact, will prevent interference with the critical
section in most cases because, unless another CPU is idle,
it is unlikely to encounter the same thread of code.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/