Re: atomic_t vs. volatile?

From: Jeff Garzik (jgarzik@mandrakesoft.com)
Date: Sun May 14 2000 - 15:19:33 EST


Manfred Spraul wrote:
>
> Jeff Garzik wrote:
> >
> >
> > Is marking these two variables "volatile" sufficient for atomicity? Or
> > is atomic_t needed?
> >
>
> cur_tx is a counter:
> volatile is not enough, unless you have external synchronization, you
> need atomic_t.
>
> But:
> * atomic_t doesn't solve all problems:
>
> val = atomic_read(&atomic_pos);
> atomic_inc(&atomic_pos);
>
> is unsafe. [but hard_start_xmit is synchronized on xmit_lock, so 8139too
> looks good ;)]

Note that atomic_dec_and_test and atomic_sub_and_test exist on most
platforms, so there are atomic operations which return values, solving
this problem.

FWIW:
x86 and IA64 have inc_and_test also.
arm and m68k only have dec_and_test.
S/390 only has inc_and_test and dec_and_test but no sub_and_test.

> * the atomic operations [atomic_inc, atomic_set_mask,...] are really
> expensive.
> On i386 SMP, the break even point for a spinlock should be 1-3
> atomic_inc calls. 2-5 calls for an irqsave spinlock.

What is the cost of spin_lock_irq vs. spin_lock_irqsave? It looks like
most of my driver code is never called w/ interrupts disabled. Are
there other restrictions which would cause one to favor
spin_lock_irqsave over spin_lock_irq?

Regards,

        Jeff

-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:24 EST