PATCH: Always use ll/sc for mips

PATCH: Always use ll/sc for mips

[H. J. Lu]

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]

The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
glibc always use ll/sc.


H.J.

[-- Attachment #2: glibc-mips-llsc.patch --]
[-- Type: text/plain, Size: 6457 bytes --]

2002-07-02  H.J. Lu  <hjl@gnu.org>

	* sysdeps/mips/pspinlock.c: Don't include <sgidefs.h>. Always
	use ll/sc.
	* sysdeps/mips/pt-machine.h: Liekwise.

2002-07-02  H.J. Lu  <hjl@gnu.org>

	* sysdeps/mips/atomicity.h: Don't include <sgidefs.h>. Always
	use ll/sc.
	* sysdeps/unix/sysv/linux/mips/sys/tas.h: Likewise.

	* sysdeps/unix/sysv/linux/configure.in: Set arch_minimum_kernel
	to 2.4.0 for mips.
	* sysdeps/unix/sysv/linux/configure: Regenerated.

--- libc/linuxthreads/sysdeps/mips/pspinlock.c.llsc	Fri Feb  8 09:08:40 2002
+++ libc/linuxthreads/sysdeps/mips/pspinlock.c	Tue Jul  2 10:58:42 2002
@@ -19,12 +19,9 @@
 
 #include <errno.h>
 #include <pthread.h>
-#include <sgidefs.h>
 #include <sys/tas.h>
 #include "internals.h"
 
-#if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
-
 /* This implementation is similar to the one used in the Linux kernel.  */
 int
 __pthread_spin_lock (pthread_spinlock_t *lock)
@@ -34,10 +31,13 @@ __pthread_spin_lock (pthread_spinlock_t 
   asm volatile
     ("\t\t\t# spin_lock\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%1,%3\n\t"
      "li	%2,1\n\t"
      "bnez	%1,1b\n\t"
      "sc	%2,%0\n\t"
+     ".set	pop\n\t"
      "beqz	%2,1b"
      : "=m" (*lock), "=&r" (tmp1), "=&r" (tmp2)
      : "m" (*lock)
@@ -46,17 +46,6 @@ __pthread_spin_lock (pthread_spinlock_t 
   return 0;
 }
 
-#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
-int
-__pthread_spin_lock (pthread_spinlock_t *lock)
-{
-  while (_test_and_set ((int *) lock, 1));
-  return 0;
-}
-
-#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
 weak_alias (__pthread_spin_lock, pthread_spin_lock)
 
 
--- libc/linuxthreads/sysdeps/mips/pt-machine.h.llsc	Wed Apr 10 11:38:44 2002
+++ libc/linuxthreads/sysdeps/mips/pt-machine.h	Tue Jul  2 10:58:21 2002
@@ -23,7 +23,6 @@
 #ifndef _PT_MACHINE_H
 #define _PT_MACHINE_H   1
 
-#include <sgidefs.h>
 #include <sys/tas.h>
 
 #ifndef PT_EI
@@ -51,8 +50,6 @@ register char * stack_pointer __asm__ ("
 
 /* Compare-and-swap for semaphores. */
 
-#if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
-
 #define HAS_COMPARE_AND_SWAP
 PT_EI int
 __compare_and_swap (long int *p, long int oldval, long int newval)
@@ -62,11 +59,14 @@ __compare_and_swap (long int *p, long in
   __asm__ __volatile__
     ("/* Inline compare & swap */\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%1,%5\n\t"
      "move	%0,$0\n\t"
      "bne	%1,%3,2f\n\t"
      "move	%0,%4\n\t"
      "sc	%0,%2\n\t"
+     ".set	pop\n\t"
      "beqz	%0,1b\n"
      "2:\n\t"
      "/* End compare & swap */"
@@ -77,6 +77,4 @@ __compare_and_swap (long int *p, long in
   return ret;
 }
 
-#endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
 #endif /* pt-machine.h */
--- libc/sysdeps/mips/atomicity.h.llsc	Fri Feb  8 09:09:06 2002
+++ libc/sysdeps/mips/atomicity.h	Tue Jul  2 10:58:05 2002
@@ -20,11 +20,8 @@
 #ifndef _MIPS_ATOMICITY_H
 #define _MIPS_ATOMICITY_H    1
 
-#include <sgidefs.h>
 #include <inttypes.h>
 
-#if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
-
 static inline int
 __attribute__ ((unused))
 exchange_and_add (volatile uint32_t *mem, int val)
@@ -34,9 +31,12 @@ exchange_and_add (volatile uint32_t *mem
   __asm__ __volatile__
     ("/* Inline exchange & add */\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%0,%3\n\t"
      "addu	%1,%4,%0\n\t"
      "sc	%1,%2\n\t"
+     ".set	pop\n\t"
      "beqz	%1,1b\n\t"
      "/* End exchange & add */"
      : "=&r"(result), "=&r"(tmp), "=m"(*mem)
@@ -55,9 +55,12 @@ atomic_add (volatile uint32_t *mem, int 
   __asm__ __volatile__
     ("/* Inline atomic add */\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%0,%2\n\t"
      "addu	%0,%3,%0\n\t"
      "sc	%0,%1\n\t"
+     ".set	pop\n\t"
      "beqz	%0,1b\n\t"
      "/* End atomic add */"
      : "=&r"(result), "=m"(*mem)
@@ -74,11 +77,14 @@ compare_and_swap (volatile long int *p, 
   __asm__ __volatile__
     ("/* Inline compare & swap */\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%1,%5\n\t"
      "move	%0,$0\n\t"
      "bne	%1,%3,2f\n\t"
      "move	%0,%4\n\t"
      "sc	%0,%2\n\t"
+     ".set	pop\n\t"
      "beqz	%0,1b\n"
      "2:\n\t"
      "/* End compare & swap */"
@@ -89,37 +95,4 @@ compare_and_swap (volatile long int *p, 
   return ret;
 }
 
-#else /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
-#warning MIPS I atomicity functions are not atomic
-
-static inline int
-__attribute__ ((unused))
-exchange_and_add (volatile uint32_t *mem, int val)
-{
-  int result = *mem;
-  *mem += val;
-  return result;
-}
-
-static inline void
-__attribute__ ((unused))
-atomic_add (volatile uint32_t *mem, int val)
-{
-  *mem += val;
-}
-
-static inline int
-__attribute__ ((unused))
-compare_and_swap (volatile long int *p, long int oldval, long int newval)
-{
-  if (*p != oldval)
-    return 0;
-
-  *p = newval;
-  return 1;
-}
-
-#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
 #endif /* atomicity.h */
--- libc/sysdeps/unix/sysv/linux/configure.in.llsc	Tue May 21 11:30:10 2002
+++ libc/sysdeps/unix/sysv/linux/configure.in	Tue Jul  2 10:32:35 2002
@@ -59,7 +59,7 @@ case "$machine" in
     libc_cv_gcc_unwind_find_fde=yes
     ;;
   mips*)
-    arch_minimum_kernel=2.2.15
+    arch_minimum_kernel=2.4.0
     libc_cv_gcc_unwind_find_fde=yes
     ;;
   powerpc*)
--- libc/sysdeps/unix/sysv/linux/mips/sys/tas.h.llsc	Fri Feb  8 09:09:06 2002
+++ libc/sysdeps/unix/sysv/linux/mips/sys/tas.h	Tue Jul  2 10:57:14 2002
@@ -21,8 +21,6 @@
 #define _SYS_TAS_H 1
 
 #include <features.h>
-#include <sgidefs.h>
-#include <sys/sysmips.h>
 
 __BEGIN_DECLS
 
@@ -34,8 +32,6 @@ extern int _test_and_set (int *p, int v)
 #  define _EXTERN_INLINE extern __inline
 # endif
 
-# if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
-
 _EXTERN_INLINE int
 _test_and_set (int *p, int v) __THROW
 {
@@ -44,10 +40,13 @@ _test_and_set (int *p, int v) __THROW
   __asm__ __volatile__
     ("/* Inline test and set */\n"
      "1:\n\t"
+     ".set	push\n\t"
+     ".set	mips2\n\t"
      "ll	%0,%3\n\t"
      "move	%1,%4\n\t"
      "beq	%0,%4,2f\n\t"
      "sc	%1,%2\n\t"
+     ".set	pop\n\t"
      "beqz	%1,1b\n"
      "2:\n\t"
      "/* End test and set */"
@@ -58,16 +57,6 @@ _test_and_set (int *p, int v) __THROW
   return r;
 }
 
-# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
-_EXTERN_INLINE int
-_test_and_set (int *p, int v) __THROW
-{
-  return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0);
-}
-
-# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
-
 #endif /* __USE_EXTERN_INLINES */
 
 __END_DECLS

Re: PATCH: Always use ll/sc for mips

[Ralf Baechle]

On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote:

> The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> glibc always use ll/sc.

Which means the overhead of two syscalls instead of one sysmips() call
for something that is assumed to be dirt cheap.  R3000, R5900 etc.
users won't this patch you, which'll have significant impact on their
glibc performance.

  Ralf

Re: PATCH: Always use ll/sc for mips

[H. J. Lu]

On Tue, Jul 02, 2002 at 10:06:51PM +0200, Ralf Baechle wrote:
> On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote:
> 
> > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> > glibc always use ll/sc.
> 
> Which means the overhead of two syscalls instead of one sysmips() call
> for something that is assumed to be dirt cheap.  R3000, R5900 etc.
> users won't this patch you, which'll have significant impact on their
> glibc performance.
> 

Not all ll/sc usages are implemented with sysmips. Does mips care about
those? In case of libstdc++, should mips use ll/sc emulation?


H.J.

Re: PATCH: Always use ll/sc for mips

[Maciej W. Rozycki]

On Tue, 2 Jul 2002, H. J. Lu wrote:

> > Which means the overhead of two syscalls instead of one sysmips() call
> > for something that is assumed to be dirt cheap.  R3000, R5900 etc.
> > users won't this patch you, which'll have significant impact on their
> > glibc performance.
> 
> Not all ll/sc usages are implemented with sysmips. Does mips care about
> those? In case of libstdc++, should mips use ll/sc emulation?

 Anything external to glibc should use _test_and_set() which is a
published interface. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Always use ll/sc for mips

[Kevin D. Kissell]

> On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote:
> 
> > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> > glibc always use ll/sc.
> 
> Which means the overhead of two syscalls instead of one sysmips() call
> for something that is assumed to be dirt cheap.  R3000, R5900 etc.
> users won't this patch you, which'll have significant impact on their
> glibc performance.

The R5900 kernel for the Playstation 2 does not use system
calls.  It uses a memory-mapped pseudo-device hack that
the guys at Sony came up with, which is much faster.  We
at MIPS came up with an even faster hack which uses 
the destruction of a "k" register value, but which requires 
the branch-likely instruction and thus only workson 
MIPS II CPUs and above (R39xxx, R4xxx, R5xxx,
but not the classic R3K).  See my message
"Re: patches for test-and-set without ll/sc" of January 22.

I consider it to be very important for MIPS/Linux
that the embedded/workstation kernel and libraries
merge with the Playstation 2 "consumer" Linux, and
I don't think that will happen if we try to push the
PS2 people to use something far less efficient than
what they already have. "Entia non sunt multiplicanda 
praeter necessitatem", as a wise old guy once said,
but could we not consider a MIPS/Linux universe
where R3000 binaries use system calls, non-LL/SC
MIPSII+ binaries use k-register destruction, real,
manly, MIPS binaries use LL/SC instructions, and
where the MIPS/Linux kernel (a) supports an appropriate
system call, (b) makes a contract with userland to 
destroy k-regs predictably, and (c) contains the
emulation logic for LL/SC?  That should give us
full cross-platform binary compatibility, with optimal
performance on each platform when an appropriately
configured set of libraries and tools is installed.

            Regards,

            Kevin K.
 

Re: PATCH: Always use ll/sc for mips

[Kevin D. Kissell]

> On Tue, Jul 02, 2002 at 11:40:45AM -0700, H. J. Lu wrote:
> 
> > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> > glibc always use ll/sc.
> 
> Which means the overhead of two syscalls instead of one sysmips() call
> for something that is assumed to be dirt cheap.  R3000, R5900 etc.
> users won't this patch you, which'll have significant impact on their
> glibc performance.

The R5900 kernel for the Playstation 2 does not use system
calls.  It uses a memory-mapped pseudo-device hack that
the guys at Sony came up with, which is much faster.  We
at MIPS came up with an even faster hack which uses 
the destruction of a "k" register value, but which requires 
the branch-likely instruction and thus only workson 
MIPS II CPUs and above (R39xxx, R4xxx, R5xxx,
but not the classic R3K).  See my message
"Re: patches for test-and-set without ll/sc" of January 22.

I consider it to be very important for MIPS/Linux
that the embedded/workstation kernel and libraries
merge with the Playstation 2 "consumer" Linux, and
I don't think that will happen if we try to push the
PS2 people to use something far less efficient than
what they already have. "Entia non sunt multiplicanda 
praeter necessitatem", as a wise old guy once said,
but could we not consider a MIPS/Linux universe
where R3000 binaries use system calls, non-LL/SC
MIPSII+ binaries use k-register destruction, real,
manly, MIPS binaries use LL/SC instructions, and
where the MIPS/Linux kernel (a) supports an appropriate
system call, (b) makes a contract with userland to 
destroy k-regs predictably, and (c) contains the
emulation logic for LL/SC?  That should give us
full cross-platform binary compatibility, with optimal
performance on each platform when an appropriately
configured set of libraries and tools is installed.

            Regards,

            Kevin K.
 

Re: PATCH: Always use ll/sc for mips

[Ralf Baechle]

On Thu, Jul 04, 2002 at 10:47:41AM +0200, Kevin D. Kissell wrote:

> The R5900 kernel for the Playstation 2 does not use system
> calls.  It uses a memory-mapped pseudo-device hack that
> the guys at Sony came up with, which is much faster.  We
> at MIPS came up with an even faster hack which uses 
> the destruction of a "k" register value, but which requires 
> the branch-likely instruction and thus only workson 
> MIPS II CPUs and above (R39xxx, R4xxx, R5xxx,
> but not the classic R3K).  See my message
> "Re: patches for test-and-set without ll/sc" of January 22.
> 
> I consider it to be very important for MIPS/Linux
> that the embedded/workstation kernel and libraries
> merge with the Playstation 2 "consumer" Linux, and
> I don't think that will happen if we try to push the
> PS2 people to use something far less efficient than
> what they already have. "Entia non sunt multiplicanda 
> praeter necessitatem", as a wise old guy once said,
> but could we not consider a MIPS/Linux universe
> where R3000 binaries use system calls, non-LL/SC
> MIPSII+ binaries use k-register destruction, real,
> manly, MIPS binaries use LL/SC instructions, and
> where the MIPS/Linux kernel (a) supports an appropriate
> system call, (b) makes a contract with userland to 
> destroy k-regs predictably, and (c) contains the
> emulation logic for LL/SC?  That should give us
> full cross-platform binary compatibility, with optimal
> performance on each platform when an appropriately
> configured set of libraries and tools is installed.

No, Sony's ABI isn't MP proof and will break silently on MP systems.  As
such I can't consider it anything else but a hack.  sysmips(MIPS_ATOMIC_SET,
...) and ll/sc however are MP proof.

  Ralf

Re: PATCH: Always use ll/sc for mips

[Hiroyuki Machida]

From: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: PATCH: Always use ll/sc for mips
Date: Thu, 4 Jul 2002 15:57:26 +0200

> No, Sony's ABI isn't MP proof and will break silently on MP systems.  As
> such I can't consider it anything else but a hack.  sysmips(MIPS_ATOMIC_SET,
> ...) and ll/sc however are MP proof.

We can support MP with few modifications.  

On MP system, the pseudo-device will provide ll/sc if CPU support
it. Otherwise, the pseudo-device will be failed to open. In this
case, sysmips() will be used as last resort in libc.

---
Hiroyuki Machida
Sony Corp.

Re: PATCH: Always use ll/sc for mips

[Jun Sun]

Ralf Baechle wrote:

> On Thu, Jul 04, 2002 at 10:47:41AM +0200, Kevin D. Kissell wrote:
> 
> 
>>The R5900 kernel for the Playstation 2 does not use system
>>calls.  It uses a memory-mapped pseudo-device hack that
>>the guys at Sony came up with, which is much faster.  We
>>at MIPS came up with an even faster hack which uses 
>>the destruction of a "k" register value, but which requires 
>>the branch-likely instruction and thus only workson 
>>MIPS II CPUs and above (R39xxx, R4xxx, R5xxx,
>>but not the classic R3K).  See my message
>>"Re: patches for test-and-set without ll/sc" of January 22.
>>
>>I consider it to be very important for MIPS/Linux
>>that the embedded/workstation kernel and libraries
>>merge with the Playstation 2 "consumer" Linux, and
>>I don't think that will happen if we try to push the
>>PS2 people to use something far less efficient than
>>what they already have. "Entia non sunt multiplicanda 
>>praeter necessitatem", as a wise old guy once said,
>>but could we not consider a MIPS/Linux universe
>>where R3000 binaries use system calls, non-LL/SC
>>MIPSII+ binaries use k-register destruction, real,
>>manly, MIPS binaries use LL/SC instructions, and
>>where the MIPS/Linux kernel (a) supports an appropriate
>>system call, (b) makes a contract with userland to 
>>destroy k-regs predictably, and (c) contains the
>>emulation logic for LL/SC?  That should give us
>>full cross-platform binary compatibility, with optimal
>>performance on each platform when an appropriately
>>configured set of libraries and tools is installed.
>>
> 
> No, Sony's ABI isn't MP proof and will break silently on MP systems.  As
> such I can't consider it anything else but a hack.  sysmips(MIPS_ATOMIC_SET,
> ...) and ll/sc however are MP proof.
> 


sysmips(MIPS_ATOMIC_SET, ...) as it is is not MP-safe.  Two processors can set 
the variable at the same time since no spinlock is used to protect the access.

This is also a problem when I was writing preemptiable kernel patch.

Jun

Re: PATCH: Always use ll/sc for mips

[Ralf Baechle]

On Mon, Jul 08, 2002 at 10:21:56AM -0700, Jun Sun wrote:

> > No, Sony's ABI isn't MP proof and will break silently on MP systems.  As
> > such I can't consider it anything else but a hack.  sysmips(MIPS_ATOMIC_SET,
> > ...) and ll/sc however are MP proof.
> > 
> 
> 
> sysmips(MIPS_ATOMIC_SET, ...) as it is is not MP-safe.  Two processors can
> set the variable at the same time since no spinlock is used to protect the
> access. 

Note there are two cases in the code, one using ll/sc which is MP proof
and a second implementation for machines that don't have these instructions.
At least for now Linux/MIPS SMP systems by definition have ll/sc, so I
don't see any problem.

> This is also a problem when I was writing preemptiable kernel patch.

Thanks for the reminder.  I'm just working on the merge with 2.5.4 which
has all the preemption stuff.  Another one for the to-do list ...

  Ralf

Re: PATCH: Always use ll/sc for mips

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Tue, 2002-07-02 at 11:40, H. J. Lu wrote:
> The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> glibc always use ll/sc.

Since I haven't seen any objections I've checked this patch in.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: PATCH: Always use ll/sc for mips

[Maciej W. Rozycki]

On 15 Jul 2002, Ulrich Drepper wrote:

> > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> > glibc always use ll/sc.
> 
> Since I haven't seen any objections I've checked this patch in.

 [I must have missed the original mail, sorry.]

 It sucks performance-wise with no visible gain, so I don't think it is
really desireable.  Since the no-ll/sc case is handled correctly, I see no
reason to remove the code.  The kernel interface is awkward, I admit, but
it works (and is even handcoded in assembly for performance gain) and we
may able to develop a better one eventually.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Always use ll/sc for mips

[H. J. Lu]

On Tue, Jul 16, 2002 at 05:22:36PM +0200, Maciej W. Rozycki wrote:
> On 15 Jul 2002, Ulrich Drepper wrote:
> 
> > > The ll/sc emulation is implemented in 2.4.0 and above. This patch makes
> > > glibc always use ll/sc.
> > 
> > Since I haven't seen any objections I've checked this patch in.
> 
>  [I must have missed the original mail, sorry.]
> 
>  It sucks performance-wise with no visible gain, so I don't think it is
> really desireable.  Since the no-ll/sc case is handled correctly, I see no

Only <sys/tas.h> is covered by the kernel interface. But it doesn't
cover atomicity.h in glibc and libstdc++.

> reason to remove the code.  The kernel interface is awkward, I admit, but
> it works (and is even handcoded in assembly for performance gain) and we
> may able to develop a better one eventually.
> 


H.J.

Re: PATCH: Always use ll/sc for mips

[Maciej W. Rozycki]

On Tue, 16 Jul 2002, H. J. Lu wrote:

> >  It sucks performance-wise with no visible gain, so I don't think it is
> > really desireable.  Since the no-ll/sc case is handled correctly, I see no
> 
> Only <sys/tas.h> is covered by the kernel interface. But it doesn't
> cover atomicity.h in glibc and libstdc++.

 Even if nobody bothered fixing these, that doesn't mean some other code
is useless.  If you don't want to implement these with _test_and_set(),
then just put equivalent ll/sc code there, which will work thanks to the
emulation.  Depending on the operation it may even be faster than
_test_and_set() as ll/sc provides a generic way to perform atomic
operations, while using _test_and_set() might require a spinlock. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Always use ll/sc for mips

[H. J. Lu]

On Wed, Jul 17, 2002 at 10:31:13AM +0200, Maciej W. Rozycki wrote:
> On Tue, 16 Jul 2002, H. J. Lu wrote:
> 
> > >  It sucks performance-wise with no visible gain, so I don't think it is
> > > really desireable.  Since the no-ll/sc case is handled correctly, I see no
> > 
> > Only <sys/tas.h> is covered by the kernel interface. But it doesn't
> > cover atomicity.h in glibc and libstdc++.
> 
>  Even if nobody bothered fixing these, that doesn't mean some other code
> is useless.  If you don't want to implement these with _test_and_set(),
> then just put equivalent ll/sc code there, which will work thanks to the
> emulation.  Depending on the operation it may even be faster than
> _test_and_set() as ll/sc provides a generic way to perform atomic
> operations, while using _test_and_set() might require a spinlock. 
> 

I am not against reversing the sysdeps/unix/sysv/linux/mips/sys/tas.h
change. But I am not so excited about it to do it myself.


H.J.