pthread_mutex_timedlock on sparc64

On Sat, Apr 22, 2006 at 04:46:13PM +1000, Sean Winn wrote:
> owner-freebsd-sparc64freebsd.org wrote:
> > Kris Kennaway wrote:
> >> On Tue, Apr 18, 2006 at 07:28:00PM +1000, Sean
Winn wrote:
> >>> owner-freebsd-sparc64freebsd.org wrote:
> >>>> 
> >>>> libthr *is* the thread library on
sparc64; as Daniel says,
> >>>> libpthread is not ported to sparc64.
> >>>> 
> >>>> Kris
> >>> 
> >>> Not yet in 6.x
> >>> 
> >>> 19:25 Tue 18-Apr seanbloody
[~] uname -msr
> >>> FreeBSD 6.1-RC1 sparc64
> >>> 19:25 Tue 18-Apr seanbloody
[~] ls -l /usr/lib/libpthread.so
> >>> lrwxrwxrwx  1 root  wheel  9 Apr 17 04:05
/usr/lib/libpthread.so ->
> >>> libc_r.so
> >> 
> >> Oops, I forgot about that..although so did
David when he removed
> >> libc_r from 7.0 and broke sparc 
> >> 
> >> So I guess this is a libc_r missing feature. 
Probably the solution
> >> is to use libthr on 6.x too (I don't know if
it works well enough on
> >> 5.x).  libthr causes witness panics under load
on sparc64 though.
> >> 
> >> Kris
> > 
> > Would threading problems be related to
sparc64/73413? I've noticed it
> > sitting idle for a long while, and the test case
still core dumps. The
> > PR it references (sparc64/72998) also is open.
> > 
> > 
> 
> And as a followup to these two PRs - the patches apply
cleanly to 6.1RC1
> and the test case in the PR certainly doesn't core
dump anymore.

Thanks.

> Using mysqld 4.1.18 with super-smack update-select has
had no panics or
> core dumps after these changes with both libkse and
libthr; all that
> means of course is that it doesn't introduce something
horribly wrong,
> not that it works - is there some regression test for
threading?
> 
> Note: all my testing is done on a single CPU AXi.

Hmm, just to confirm, you were seeing core dumps with
super-smack
before you applied the changes?  Because I have run that
extensively
on MP sparc machines without issues.

Kris