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" <[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.
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. > 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]
