Subject: MIPS_ATOMIC_SET in sys_sysmips()

From: Jun Sun <[email-masked]>
Date: Mon, 18 Dec 2000 18:03:43 -0800

It looks like sometime after test5 the MIPS_ATOMIC_SET case in sys_sysmips()
function in the CVS tree is changed.  The new code now uses ll/sc instructions
and handles syscall trace, etc.. 

This change does not make sense to me.  The userland typically uses
MIPS_ATOMIC_SET when ll/sc instructions are not available.  But the new code
itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss
something else?

What do we offer to machines without ll/sc?

BTW, what is the wrong with previous code?  I understand it may be broken in
SMP case, but I think that is fixable.  Comments?

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 19 Dec 2000 14:25:33 +0100 (MET)

> itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss

 There is no problem with using ll/sc in sysmips() itself for machines
that support them. 

> What do we offer to machines without ll/sc?

 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. 

> SMP case, but I think that is fixable.  Comments?

 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. 

  Maciej

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

---

From: Harald Koerfgen <[email-masked]>
Date: Tue, 19 Dec 2000 18:03:01 +0100 (CET)

> a well-known defined behaviour. 

Another possibility would be to rely on the userland ll/sc emulation in the
kernel. The one in the linux-vr tree seems to be working well and can easily be
backported to Linux/MIPS.

Advantage: userland binary compatibility.
Disadvantage: possibility for a lot of context switches for userland atomic
operations.
 
Having a sysmips(MIPS_ATOMIC_SET, ...) or atomic_op() solution would probably a
lot faster.

Maybe we should implement both :)

-- 
Regards,
Harald

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 19 Dec 2000 19:03:00 +0100 (MET)

> backported to Linux/MIPS.

 This should work but it looks ugly to me and the performance would suck
horribly. 

> Disadvantage: possibility for a lot of context switches for userland atomic

 We may implement the emulation anyway, just like we emulate unaligned
accesses. 

> Maybe we should implement both :)

 If we could afford another syscall number then I would prefer atomic_op() 
at the moment as it is well-documented and it does not overload one
function for various purposes, i.e. it's a bit faster. 

  Maciej

---

From: Jun Sun <[email-masked]>
Date: Tue, 19 Dec 2000 10:38:35 -0800

>  There is no problem with using ll/sc in sysmips() itself for machines

Sure - but with ll/sc available the user programs don't need to issue
sysmip(MIPS_ATOMIC_SET,...) at the first place ...

> a well-known defined behaviour.

Where can I find the definitino of atomic_op()?  Or can you tell us a little
more about it? 

> 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.

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 20 Dec 2000 14:24:37 +0100 (MET)

> 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.

> Where can I find the definitino of atomic_op()?  Or can you tell us a little

 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.

> 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.

                                                                 atomic_op(2)

   Name
     atomic_op - perform test and set operation.

   Syntax
     #include <sys/lock.h>

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

   Arguments

     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.

   Description
     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.

   Diagnostics

     [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.