pthread_mutex_timedlock on sparc64

Sean Winn sean at gothic.net.au
Sat Apr 22 06:46:26 UTC 2006


owner-freebsd-sparc64 at freebsd.org wrote:
> Kris Kennaway wrote:
>> On Tue, Apr 18, 2006 at 07:28:00PM +1000, Sean Winn wrote:
>>> owner-freebsd-sparc64 at freebsd.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 sean at bloody [~] uname -msr
>>> FreeBSD 6.1-RC1 sparc64
>>> 19:25 Tue 18-Apr sean at bloody [~] 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.

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.


> http://www.freebsd.org/cgi/query-pr.cgi?pr=sparc64/73413
> 
> _______________________________________________
> freebsd-sparc64 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to
> "freebsd-sparc64-unsubscribe at freebsd.org"




More information about the freebsd-threads mailing list