Messages in this thread | | | Date | Thu, 05 Feb 2004 17:56:37 -0500 | From | Brian Gerst <> | Subject | Re: [Infiniband-general] Getting an Infiniband access layer in theLinux kernel |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |