On Tue, 2008-10-28 at 23:51 +0000, sebb wrote: > On 28/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > 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" <httpclient-users@hc.apache.org> > > > > 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. > > As far as I know this is not the case unless the variable is final, > volatile, or set up during class initialisation. Otherwise, the JVM is > free to cache the written or previously read value. > > Whether it does so is another matter; there's nothing to stop the the > JVM from flushing the variable earlier. So unsafe code may still work. > > However, if the writer thread and reader thread(s) both synchronise on > the same object then any variables that were set before the synch > calls will be seen by the other thread - the variables don't have to > set as part of the synch block. This is part of the "happens-before" > rule, if I've understood it correctly. >
While this is certainly true, it is very unlikely this can affect HttpParams given the fact they are initialized when HttpClient instance is created and then read from _much_ later in time (many, many CPU cycles after) when requests are executed. Oleg > > 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] > > > > > > --------------------------------------------------------------------- > 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]
