Linux PARISC architecture development
 help / color / mirror / Atom feed
* [parisc-linux] atomic_t
@ 2002-01-13 21:15 Matthew Wilcox
  2002-01-14  4:09 ` Grant Grundler
  0 siblings, 1 reply; 6+ messages in thread
From: Matthew Wilcox @ 2002-01-13 21:15 UTC (permalink / raw)
  To: parisc-linux

Just thinking about atomic_set taking the spinlock to assure
exclusivity...  I thought we could eliminate it.

Here's the current code:

static __inline__ void __atomic_set(atomic_t *v, int i) 
{
        unsigned long flags;
        SPIN_LOCK_IRQSAVE(ATOMIC_HASH(v), flags);

        v->counter = i;

        SPIN_UNLOCK_IRQRESTORE(ATOMIC_HASH(v), flags);
}

static __inline__ int __atomic_add_return(int i, atomic_t *v)
{
        int ret;
        unsigned long flags;
        SPIN_LOCK_IRQSAVE(ATOMIC_HASH(v), flags);

        ret = (v->counter += i);

        SPIN_UNLOCK_IRQRESTORE(ATOMIC_HASH(v), flags);
        return ret;
}

The legitimate effect of having two processors do this at the same time
are:

atomic_t v = 3

case 1:

atomic_add_return(1, &v)
atomic_set(&v, 1)
result: v = 1, a_a_r returns 4.

or case 2:

atomic_set(&v, 1)
atomic_add_return(1, &v)
result: v = 2, a_a_r returns 2.

The spinlocks guarantee this behaviour, but let's look at what happens
if we remove the spinlock from atomic_set.  Now atomic_set is just an
assignment, and can occur at any point during atomic_add_ret.  We'll have
to drop to psuedo-assembler for this.

atomic_add_ret becomes:

a) lock
b) load v into register r
c) add 1 to r
d) store r to v
e) unlock
f) return r

atomic_set (store 1 to v) can appear to occur at any point -- the CPU
ref manual guarantees it won't cause any problems.

Before step b leads to case 2.  after step d leads to case 1.  between
steps b and d, it's as if the atomic_set _never_happened_.  It results
in v=4, a_a_r returns 4.

The question is whether any code relies on this behaviour.  It probably
does in some of the messier bits of networking :-(

-- 
Revolutions do not require corporate support.

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [parisc-linux] atomic_t
@ 2002-01-14  6:54 John Marvin
  0 siblings, 0 replies; 6+ messages in thread
From: John Marvin @ 2002-01-14  6:54 UTC (permalink / raw)
  To: parisc-linux

> >
> > But someone thought it was time to reset the counter. And if
> > it "never happened", then whoever is looking for 'v == 1' will
> > never see it.
>
> It's a race though; they can't guarantee to see it anyway.
>

Yes, it is a race in that you can't be guaranteed that you will ever see
the value equal to 1. But you should be guaranteed that it WAS reset.

For example:

    1) Initialize counter to 1.
    2) Increment counter by 1 each time event "X" occurs using
       atomic_add_return.
    3) Reset counter to 1 each time event "Y" occurs using atomic_set.
    4) Signal an error if the counter ever exceeds some threshold
       value, i.e. it is an error if too many "X" events occur without
       and intervening "Y" event.

In the above scenario you could not be guaranteed that you would ever see
the counter at one (or any particular value), but you could falsely
trigger the error condition if the resets were lost (by removing the
spinlocks from atomic_set).

John

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-01-14  9:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-13 21:15 [parisc-linux] atomic_t Matthew Wilcox
2002-01-14  4:09 ` Grant Grundler
2002-01-14  4:43   ` Matthew Wilcox
2002-01-14  7:12     ` Grant Grundler
2002-01-14  9:54   ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2002-01-14  6:54 John Marvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox