Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 2006 07:07:09 +0800
From:      David Xu <davidxu@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        Chris <chrcoluk@gmail.com>
Subject:   Re: libpthread vs libthr.
Message-ID:  <200611130707.10220.davidxu@freebsd.org>
In-Reply-To: <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com>
References:  <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 12 November 2006 07:03, Chris wrote:
> On 10/11/06, Nikolay Pavlov <quetzal@zone3000.net> wrote:
> > Hi. In this post i am not trying to raise a discussion about teoretical
> > advantages of some special threading model, but still i would like to
> > figure out why libthr in it current state is not our default posix
> > thread library and could it be so in time of 7-STABLE?
> >
> > As a user and administrator of FreeBSD i want to mention some benefits
> > of libthr:
> >
> > 1. It's simpler.
> > 2. It's stable and has been used by many of us for a long time.
> > 3. It proved to be very productive on real world applications.
> > 4. It has active talented developers.
> > 5. If it was a default library it would couse a incrase of users
> > feedback which would lead to futher improvement of it's code by the time
> > 7 becomes a stable branch.
> >
> > And some flaws of libpthread:
> >
> > 1. It's more difficult.
> > 2. It's slow in compare of libthr.
> > 3. The last, but the worst. IMHO the position under which libpthread is
> > the library by default is the source of a bad myth that threading model
> > in FreeBSD sucks and threading applications is slow. If 7.0 had libthr
> > as a default posix threads library we could brake that belief.
> >
> > This point of view may seem one-sided that is why someone with good
> > knowledge of the current state of code could tell other pros and cons
> > of both libraries.
> >
> > Another interesting question is which of the libraries will better work
> > with multikernel and multiprocessor systems which will be very popular
> > by the time 7.0 branch launches its stable releases.
> >
> > --
> > ======================================================================
> > - Best regards, Nikolay Pavlov. <<<-----------------------------------
> > ======================================================================
>
> HI I posted in another thread about how my own experiences seem to
> differ from all these benchmarks, they are based on 3 heavily loaded
> web/mysql servers.
>
> One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd
> 6.1 and 3rd is another dual xeon freebsd 6.1.
>
> All 3 of these machines perform better as well as more stable under
> higher loads using libpthread process scope.
>
> System scope appears to make mysql hog the system and everything slows
> down except of course mysql.
>
> Libthr appears to make mysql very sporadic with some requests fast
> others with a unexplained 5-10 sec delay including timeouts.
>
> Process scope on libpthread gives me the best results not making mysql
> starve the server of resources and it has a consistent response time
> of under 2 seconds under hevay loads.
libthr on FreeBSD 6.1 respects process scope, if your mysql is compiled
with process scope, it will use it, this is only removed in -CURRENT, 
I don't know why you said that it starved server resource if KSEGRP
really works as expected.
 
>
> I cant explain other then it maybe that test mysql data isnt a proper
> way to test these threading libraries only real work loads can.
>
> Chris
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611130707.10220.davidxu>