Re: [Infiniband-general] Getting an Infiniband access layer in theLinuxkernel

[Brian Gerst]

Tillier, Fabian wrote:
> 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();
> }

I guess you missed this then:
/**
 * atomic_dec_and_test - decrement and test
 * @v: pointer of type atomic_t
 *
 * Atomically decrements @v by 1 and
 * returns true if the result is 0, or false for all other
 * cases.  Note that the guaranteed
 * useful range of an atomic_t is only 24 bits.
 */

There is also atomic_dec_and_lock():
/*
 * This is an architecture-neutral, but slow,
 * implementation of the notion of "decrement
 * a reference count, and return locked if it
 * decremented to zero".
 *
 * NOTE NOTE NOTE! This is _not_ equivalent to
 *
 *      if (atomic_dec_and_test(&atomic)) {
 *              spin_lock(&lock);
 *              return 1;
 *      }
 *      return 0;
 *
 * because the spin-lock and the decrement must be
 * "atomic".
 *
 * This slow version gets the spinlock unconditionally,
 * and releases it if it isn't needed. Architectures
 * are encouraged to come up with better approaches,
 * this is trivially done efficiently using a load-locked
 * store-conditional approach, for example.
 */

--
				Brian Gerst
-
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/