lkml.org 
[lkml]   [2004]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRE: [Infiniband-general] Getting an Infiniband access layer in theLinux kernel
    Date
    From
    Greg,

    I'm not arguing about the spinlocks here, and never have. I'm arguing
    about the atomic abstraction for the x86 platforms. My last question
    was not a yes/no question so I'm not sure what you're answering with
    your "No" - your reply makes no sense. To clarify, the answer to a
    "chose one of two things" question is not "No". Basic XOR logic is all
    that's needed here. I'm not sure what you're asking about with the
    whole quotations thing.

    Having atomic operations return a value allows one to do something like
    test for zero when decrementing an atomic variable such as a reference
    count, to determine whether final cleanup should proceed. This removes
    the need for an actual spinlock protecting the reference count. As you
    know, reading the value post-decrement does not guarantee that said
    value reflects the result of only that decrement operation. It would be
    catastrophic if two threads checked the value of a reference count
    without proper synchronization - they could both end up running the
    cleanup code with undesired (and perhaps catastrophic) results.

    I'll try a simple example for you assuming atomic_dec returns the
    decremented value:

    if( atomic_dec( x ) == 0 )
    {
    cleanup();
    }

    In the current implementation of atomic operations for x86 however,
    atomic_dec doesn't return anything. To get the proper behavior would
    require a true spinlock because the following code sample would not work
    properly since there's no atomicity guaranteed between the decrement and
    the read:

    atomic_dec( x )
    if( atomic_read( x ) == 0 )
    {
    cleanup();
    }

    So without returning the result of the decrement, you lose the ability
    to use atomic variables for reference counting.

    Hope this clarifies things for you,

    - Fab


    -----Original Message-----
    From: Greg KH [mailto:greg@kroah.com]
    Sent: Thursday, February 05, 2004 1:27 PM
    To: Tillier, Fabian
    Cc: Randy.Dunlap; sean.hefty@intel.com; linux-kernel@vger.kernel.org;
    hozer@hozed.org; woody@co.intel.com; bill.magro@intel.com;
    woody@jf.intel.com; infiniband-general@lists.sourceforge.net
    Subject: Re: [Infiniband-general] Getting an Infiniband access layer in
    theLinux kernel

    A: No.
    Q: Should I include quotations after my reply?

    On Thu, Feb 05, 2004 at 03:32:09PM -0500, Tillier, Fabian wrote:
    > So which is more important to the "Linux kernel" project: i386
    backwards
    > compatibility, or consistent API and functionality across processor
    > architectures? ;)

    Anyway, why not describe what you are trying to accomplish that made you
    determine that you _had_ to have these kinds of functions.

    Basically, what is lacking in the current kernel locks that the
    infiniband project has to have in order to work properly. We can work
    from there.

    thanks,

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

    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:3.363 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site