[Top] [All Lists]

Re: MIPS_ATOMIC_SET in sys_sysmips()

To: Jun Sun <>
Subject: Re: MIPS_ATOMIC_SET in sys_sysmips()
From: "Maciej W. Rozycki" <>
Date: Wed, 20 Dec 2000 14:24:37 +0100 (MET)
Cc: Ralf Baechle <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <>
On Tue, 19 Dec 2000, Jun Sun wrote:

> >  There is no problem with using ll/sc in sysmips() itself for machines
> > that support them.
> Sure - but with ll/sc available the user programs don't need to issue
> sysmip(MIPS_ATOMIC_SET,...) at the first place ...

 You may be running a MIPS I binary on a MIPS II+ SMP system and the
binary has to run absolutely correctly.  Programs affected include ones
that use threads or that use locks in shared memory.

> >  I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...)
> > call before I write better code.  No response so far.  I'm now really
> > cosidering implementing the Ultrix atomic_op() syscall -- at least it has
> > a well-known defined behaviour.
> Where can I find the definitino of atomic_op()?  Or can you tell us a little
> more about it? 

 You may search the Net for atomic_op -- you should find a couple of
Ultrix man pages.  A copy is included below for your convenience.

> >  The previous code was definitely broken -- depending on the path taken it
> > would return either the value fetched from memory or an error code.  No
> > way to distinguish between them.
> I notice that.  I notice glibc is the only "customer" of the MIPS_SET_ATOMIC
> call, the bug does not appear to be a big deal because error should not
> happen.  Of course, it will be nice to fix it.

 It is at the moment, but I can see other users once we establish the API. 
PostgreSQL is one of them.  It would call _test_and_set() but it implies
the latter should work as expected.  The _test_and_set() function is
documented in the MIPS ABI supplement and the underlying syscall
(whichever it is) must provide means for the fuction to behave as
expected.  Besides, if we want this to be a compatibility call, then we
should at least make it behave in a compatible way.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +


     atomic_op - perform test and set operation.

     #include <sys/lock.h>

     int atomic_op(op, addr)
     int op;
     int *addr;


     op             This argument is the operation type.  If the operation
                    type is ATOMIC_SET, this call specifies the test and set
                    operation on location addr.  If the operation type is
                    ATOMIC_CLEAR, this call specifies the clear operation on
                    location addr.

     addr           This is the target address of the operation.

     The atomic_op call provides test and set operation at a user address.

     For RISC systems, atomic_op is executed as a system call.  For VAX sys-
     tems, a system call is not executed for this library function.

   Return Values
     If the atomic_op operation succeeds, then 0 is returned.  Otherwise a -1
     is returned, and a more specific error code is stored in errno.


     [EBUSY]        The location specified by addr is already set.

     [EINVAL]       The op is not a valid operation type.

     [EACCES]       The address specified in addr is not write accessible.

     [EALIGN]       The addr is not on an integer boundary.

<Prev in Thread] Current Thread [Next in Thread>