On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote: > --- On Mon, 10/27/08, sebb <[EMAIL PROTECTED]> wrote: > > > From: sebb <[EMAIL PROTECTED]> > > Subject: Re: MultithreadedHttpConnectionManager and high loads > > To: "HttpClient User Discussion" <[email protected]> > > Date: Monday, October 27, 2008, 12:03 PM > > On 27/10/2008, De Groot, Cees > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > We're using HC in order to access an internal > > high-volume service > > > (thousands reqs/sec), and we noticed that > > DefaultHttpParams is > > > synchronized all over the place. This kills > > concurrency (I have a thread > > > dump showing ~1200 threads waiting there ;-)), and I > > don't think it is > > > necessary - it should be possible to read settings > > without having to > > > acquire locks first. > > > > That's not necessarily true. Synchronize does more than > > provide mutual exclusion - i.e. locking - it also ensures that fields > > written in one thread are correctly seen in another. > > This is certainly correct and good point (details of how the memory view > syncing is done can be even more complicated than simple flush, conceptually > it's a memory barrier). For anyone unfamiliar with the concept (mutex and > memory consistency) should read "Java Memory Model" article: > > http://www.cs.umd.edu/~pugh/java/memoryModel/ > > Anyway, one thing I was wondering was whether syncs (or, the alternative, > using volatile) could still be avoided for default values. > This because it would seem like such values would be immutable? >
This is indeed the case. HttpParams are used in write once / ready many mode and therefore its methods do not necessarily need to be synchronized to be threading safe. HttpClient 4.0 uses unsynchronized implementation of HttpParams per default Oleg > -+ Tatu +- > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
