[lkml]   [2005]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.

    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;

    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.

    Dick Johnson
    Penguin : Linux version 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 - 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-07 16:35    [W:0.024 / U:121.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site