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

[Brian Gerst <bgerst@didntduck.org>]

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