On Sat, Nov 10, 2018 at 9:07 AM Oleg Kalnichevski <[email protected]> wrote:
> On Sat, 2018-11-10 at 08:59 -0700, Gary Gregory wrote: > > On Sat, Nov 10, 2018 at 8:51 AM Gary Gregory <[email protected]> > > wrote: > > > > > On Sat, Nov 10, 2018 at 4:29 AM Oleg Kalnichevski <[email protected] > > > > > > > wrote: > > > > > > > On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote: > > > > > On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski < > > > > > [email protected]> > > > > > > > > ... > > > > > > > > > > > > > > > Yes, it is. What would be the point if every single method > > > > > > synchronizes > > > > > > on exchangeState instance? > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/examples/org/apache/hc/core5/http/examples/AsyncReverseProxyExample.java#L275 > > > > > > > > > > > > > > > OK, I can buy that all of the synchronized blocks are correct > > > > > and > > > > > schedule > > > > > thread access to those ivars. > > > > > But what about the absence of volatile causing threads to miss > > > > > updates to > > > > > fields from other threads? > > > > > > > > > > > > > Java runtime guarantees the state of variables inside > > > > synchronized > > > > block to be consistent for all threads of execution. The reason > > > > for > > > > making variables volatile is to avoid having to use > > > > expensive synchronization. > > > > > > > > > > Hi Oleg, > > > > > > I am looking for confirmation of this in the JLS to make sure my > > > app is on > > > solid ground. I found: > > > > > > "An unlock (synchronized block or method exit) of a monitor > > > *happens-before* every subsequent lock (synchronized block or > > > method > > > entry) of that same monitor. And because the *happens-before* > > > relation is > > > transitive, all actions of a thread prior to unlocking *happen- > > > before* all > > > actions subsequent to any thread locking that monitor." > > > > > > in > > > > > https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility > > > > > > which I read as JLS-ese of your statement. > > > > > > Check? > > > > > > > Hi Oleg, > > > > Would you then say that we are missing a synchronized statement > > in > > org.apache.hc.core5.http.examples.AsyncReverseProxyExample.IncomingEx > > changeHandler.handleRequest(...).new > > FutureCallback() {...}.failed(Exception) ? > > > > I no longer remember why I omitted it. Probably it was by mistake. Feel > free to add synchronization. > Ok, done. Gary > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
