You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Gary Gregory <ga...@gmail.com> on 2018/11/09 20:42:10 UTC
Threads and org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
HI All:
Since
a org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
is accessed from different threads, I am wondering if some of its fields
are not volatile.
Also, ProxyBuffer subclasses a non-thread-safe class. Is that really
intentional?
Gary
Re: Threads and org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 10, 2018 at 9:07 AM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2018-11-10 at 08:59 -0700, Gary Gregory wrote:
> > On Sat, Nov 10, 2018 at 8:51 AM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > > On Sat, Nov 10, 2018 at 4:29 AM Oleg Kalnichevski <olegk@apache.org
> > > >
> > > wrote:
> > >
> > > > On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote:
> > > > > On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <
> > > > > olegk@apache.org>
> > > >
> > > > ...
> > > >
> > > > >
> > > > > > 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Threads and
org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2018-11-10 at 08:59 -0700, Gary Gregory wrote:
> On Sat, Nov 10, 2018 at 8:51 AM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > On Sat, Nov 10, 2018 at 4:29 AM Oleg Kalnichevski <olegk@apache.org
> > >
> > wrote:
> >
> > > On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote:
> > > > On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <
> > > > olegk@apache.org>
> > >
> > > ...
> > >
> > > >
> > > > > 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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Threads and org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 10, 2018 at 8:51 AM Gary Gregory <ga...@gmail.com> wrote:
> On Sat, Nov 10, 2018 at 4:29 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
>
>> On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote:
>> > On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <ol...@apache.org>
>>
>> ...
>>
>> >
>> > > 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.IncomingExchangeHandler.handleRequest(...).new
FutureCallback() {...}.failed(Exception) ?
Gary
>
> Gary
>
>
>> Oleg
>>
>>
>> > Gary
>> >
>> >
>> > >
>> > >
>> > > Oleg
>> > >
>> > >
>> > > -----------------------------------------------------------------
>> > > ----
>> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > > For additional commands, e-mail: dev-help@hc.apache.org
>> > >
>> > >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
Re: Threads and org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 10, 2018 at 4:29 AM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote:
> > On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <ol...@apache.org>
>
> ...
>
> >
> > > 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?
Gary
> Oleg
>
>
> > Gary
> >
> >
> > >
> > >
> > > Oleg
> > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Threads and
org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2018-11-09 at 15:36 -0700, Gary Gregory wrote:
> On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <ol...@apache.org>
...
>
> > 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.
Oleg
> Gary
>
>
> >
> >
> > Oleg
> >
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Threads and org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 9, 2018 at 3:33 PM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2018-11-09 at 13:42 -0700, Gary Gregory wrote:
> > HI All:
> >
> > Since
> > a
> > org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExcha
> > ngeState
> > is accessed from different threads, I am wondering if some of its
> > fields
> > are not volatile.
> >
> > Also, ProxyBuffer subclasses a non-thread-safe class. Is that really
> > intentional?
> >
> > Gary
>
> 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?
Gary
>
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Threads and
org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExchangeState
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2018-11-09 at 13:42 -0700, Gary Gregory wrote:
> HI All:
>
> Since
> a
> org.apache.hc.core5.http.examples.AsyncReverseProxyExample.ProxyExcha
> ngeState
> is accessed from different threads, I am wondering if some of its
> fields
> are not volatile.
>
> Also, ProxyBuffer subclasses a non-thread-safe class. Is that really
> intentional?
>
> Gary
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
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org