atom feed18 messages in org.freebsd.freebsd-threadspatch for threads/76690 - critical - ...
FromSent OnAttachments
Andriy TkachukMar 2, 2005 2:56 pm 
Daniel EischenMar 2, 2005 3:47 pm 
Andriy TkachukMar 3, 2005 6:35 am 
Daniel EischenMar 3, 2005 6:46 am 
David XuMar 3, 2005 6:48 am 
Andriy TkachukMar 3, 2005 6:58 am.patch
Andriy TkachukMar 3, 2005 7:29 am.cc
Andriy TkachukMar 3, 2005 8:07 am 
Andriy TkachukMar 3, 2005 8:10 am 
Andriy TkachukMar 3, 2005 8:15 am 
David XuMar 3, 2005 8:15 am 
Andriy TkachukMar 3, 2005 8:44 am 
Andriy TkachukMar 3, 2005 9:26 am.patch2
David XuMar 3, 2005 10:46 am 
Daniel EischenMar 3, 2005 3:14 pm 
Julian ElischerMar 3, 2005 8:29 pm 
David XuMar 4, 2005 3:24 am 
Andriy TkachukMar 4, 2005 5:57 am 
Subject:patch for threads/76690 - critical - fork hang in child for-lc_r
From:David Xu (davi@freebsd.org)
Date:Mar 3, 2005 8:15:49 am
List:org.freebsd.freebsd-threads

Hmm, libc_r and libpthread handle spinlock differently which malloc uses to protect itself, some real world benchmarks are better than this.

David Xu

Andriy Tkachuk wrote:

But if one wants to use pure user threads on his UP system, what he will chose if not libc_r ?

And i have some test program with shows the better results for libc_r than for libpthreads. Take a look.

The program is the 500 threads, each of them allocate memory in loop and then free it in another loop. Program outputs the time consumed for this two loops.

See the results.