lkml.org 
[lkml]   [2004]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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