[[ CC'd to port-mips to - these aren't just pmax issues ]]

Bob Lantz wrote:

> I seem to recall that problems with pthreads, mySQL, etc. were related to       
> not having ll/sc or an atomic store syscall on non-R4000 mips NetBSD            
> systems.                                                                        

The problems with the databases are usually TAS problems (ie, ll/sc, or
lack of [1]).
There are some patches for pthreads that mostly work, but threads that
use floating point fail badly.  I'll see if I can dig those patches up
and have another look.

> I wonder why you can't just use the memory system for synchronization -
> there are probably a number of synchronization algorithms that would work,
> and these wouldn't have the overhead of a system call,

I'm curious as to what you have in mind here?  AFAICR, at least
postgresql just requires a TAS function - how it's implemented doesn't
matter.  Do you have any pointers to these "memory synchronization
algorithms"?  I have a reference to a "lazy" TAS implementation[2] that
still requires kernel assistance.  Other options are a TAS-style syscall
(maybe even a MIPS-specific sysarch() call that mimics the Ultrix
atomic_op() syscall that can also be used in compat_ultrix) or using
SYSV semaphores.

Simon.

[1]  This one is very annoying.  Some of the HPCMIPS processors claim
     to be MIPS3, yet don't implement those instructions!!

[2]  Thanks to Nathan Williams for this one - Fast Mutual Exclusion for
     Uniprocessors by Brian N. Bershad, David D. Redell, John R. Ellis,
     look at
http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/Rcs.html
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/