380239 - Implement PR_StackPush / PR_StackPop natively on Solaris Sparc v8/v9

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect)

Description

[Julien Pierre]

The pages at
http://docs.sun.com/app/docs/doc/816-1681/6m83631kr?a=view
http://docs.sun.com/app/docs/doc/816-1681/6m83631m0?a=view

imply that there are CAS (compare and swap) instructions available on Sparc, which could be used to implement PR_StackPush and PR_StackPop .

Comment 1

[Brian King [:kinger]]

Julien, I think you flagged this as blocking the wrong bug (195192).

Comment 2

[Wan-Teh Chang]

PR_StackPop implemented using CAS is vulnerable to the ABA problem.
To avoid the ABA problem, you need either
- a pair of "load linked" and "store conditional" instructions,
  available on processors such as Alpha and PowerPC, or
- a "wide" or "double" (don't know what the right term is) CAS
  instruction that can compare and swap a pointer and a generation
  count together.

So for Solaris on SPARC and x86/x64, the only working solution is
the second one -- if a 32-bit application is running on a 64-bit
processor, you can use the CAS instruction for 64-bit word to
compare and swap a 32-bit pointer and a 32-bit generation count
packed into a 64-bit word.  You'll need to set up a filter library.
I think it's not worth the trouble.

Comment 3

[Julien Pierre]

Wan-Teh,

We already have an implementation of PR_Stackpush / PR_Stackpop with CAS for windows x86 . How does it deal with the ABA problem ?

A filter library would be necessary only if we have multiple CPUs of the same architecture with different instruction sets, some of them offering CAS instructions and some not. For Sparcv9 at least, it seems the CAS is part of the base instruction set, so we shoulidn't need multiple binaries.
And if it's part of Sparcv8 too as the docs imply. So if that's true, no separate filter libraries would be needed. Or am I missing something ?

Comment 4

[Wan-Teh Chang]

The _PR_HAVE_ATOMIC_CAS macro name is misleading.  Originally
it meant the platform has the CAS instruction.  Now it means
we have a platform-specific implementation of PR_StackPush/PR_StackPop,
which doesn't necessarily use the CAS instruction.

The PR_StackPush/PR_StackPop implementation in ntmisc.c doesn't
use CAS (cmpxchg).  It uses the swap (xchg) instruction to implement
spin locks.  Spin locks have their own problems (we had trouble
with them on Solaris).

The solution I described for Solaris needs a CAS instruction
for a 64-bit value or two 32-bit values.  This instruction
is called DCAS (do a web search for "DCAS atomic").  I don't
know if SPARC v8 has such an instruction.

Unfortunately I just realized that PRStackElem is a public
type, so we can only use the DCAS instruction on branch new
platforms, where we can define PRStackElem as:

  struct PRStackElemStr {
      PRStackElem *prstk_elem_next;
      PRInt32 generation_count;
  };