Subject: Re: Test and set (was Re: postgreSQL)
To: Jason Thorpe <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 05/29/1999 14:34:20
Jason Thorpe wrote:
> On Fri, 28 May 1999 17:36:43 +1000
> Simon Burge <firstname.lastname@example.org> wrote:
> > > atomic_value_t v1 = ATOMIC_INIT_RESET;
> > > atomic_value_t v2 = ATOMIC_INIT_SET;
> > >
> > > int atomic_set(atomic_value_t *v);
> > > set *v; return 1 if it wasn't already set.
> > > void atomic_reset(atomic_value_t *v);
> > > reset *v.
> > > int atomic_isset(atomic_value_t *v);
> > > return 1 if *v is set, otherwise 0.
> > And this interface would live in <atomic.h> or <sys/atomic.h>? If
> > we need a kernel implementation (as for older MIPS chips), then
> > <sys/atomic.h> would be the way to go...
> > I'll put together a full proposal.
> <machine/atomic.h> is the right thing, I think, since it's inherently
I was thinking along the lines of <sys/atomic.h> more or less just
including <machine/atomic.h>, but I guess there's no need for the
extra level on indirection.
> Also note some of the atomic operations that arch/alpha/alpha/atomic.s
> - atomic test-and-set (for spin locks)
> - atomic load-and-latch (for atomically reading a counter and
> resetting it to zero, for example)
I was only thinking in terms of Bill's interface for now. Would this
do for now? One thing that's missing is the size of "atomic_value_t".
Maybe that should be "atomic_set32" and so on...
Am I right in saying that each new interface to atomic operations
would require bumping either libc's minor number and/or the kernel's
alphabetic release number, even if only one architecture extends the