[concurrency-interest] Unsynchronized lazy conditions

David Holmes davidcholmes at aapt.net.au
Thu May 31 20:33:31 EDT 2018


Classloading can be lazy or eager. Class initialization is very precise.

David

> -----Original Message-----
> From: Concurrency-interest <concurrency-interest-bounces at cs.oswego.edu> On Behalf Of Shevek via Concurrency-interest
> Sent: Friday, June 1, 2018 8:49 AM
> To: Yuval Shavit <yankee.sierra at gmail.com>; Carl Mastrangelo <notcarl at google.com>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Unsynchronized lazy conditions
> 
> My question is the converse: It does NOT say "will not be initialized UNLESS." That makes the Effective Java trick less useful for this
> case:
> I don't mind more than one call to log() when at least one is allowed, but if the guard condition never passes, I mustn't have spurious
> calls.
> 
> On 05/31/2018 02:42 PM, Yuval Shavit wrote:
> > JLS 12.4.1 says: "A class or interface typeTwill be initialized
> > immediately before the first occurrence of any one of the following."
> >
> > They don't define "immediately," but I think it's reasonable to assume
> > that it's more or less in line with people's intuition about lazy loading.
> >
> > On Thu, May 31, 2018 at 4:16 PM, Carl Mastrangelo via
> > Concurrency-interest <concurrency-interest at cs.oswego.edu
> > <mailto:concurrency-interest at cs.oswego.edu>> wrote:
> >
> >     As I understand it, class loading is lazy and this will do the right
> >     thing.  It *may* get garbage collected if not referenced (and maybe
> >     log twice), but that can be worked around.  The pattern is very
> >     common for singletons.
> >
> >     On Thu, May 31, 2018 at 1:10 PM Shevek <shevek at anarres.org
> >     <mailto:shevek at anarres.org>> wrote:
> >
> >         I know there's a guarantee that the JVM _will_ call this when
> >         desired.
> >         Is there also a guarantee that the JVM will _not_ call this i.e.
> >         there
> >         is no spurious class or opportunistic initialization? I think
> >         that's
> >         harder to promise.
> >
> >         On 05/31/2018 01:06 PM, Carl Mastrangelo wrote:
> >          > At the cost of about 500 bytes of class size, you could do
> >         the trick in
> >          > Effective Java:
> >          >
> >          > class Foo {
> >          >     private static class Logged {
> >          >       static void log() {}
> >          >        static {
> >          > LOG.warn("Warning");
> >          >        }
> >          >     }
> >          >
> >          >     public void run() {
> >          > Logged.log();
> >          >     }
> >          > }
> >          >
> >          > On Wed, May 30, 2018 at 10:17 PM Shevek via Concurrency-interest
> >          > <concurrency-interest at cs.oswego.edu
> >         <mailto:concurrency-interest at cs.oswego.edu>
> >          > <mailto:concurrency-interest at cs.oswego.edu
> >         <mailto:concurrency-interest at cs.oswego.edu>>> wrote:
> >          >
> >          >     Hi,
> >          >
> >          >     I'd like to issue a warning message a relatively low
> >         number of times in
> >          >     a multi-threaded application. My code is this:
> >          >
> >          >     class Foo {
> >          >         private boolean warned;
> >          >
> >          >         public void run() {
> >          >           if (!warned) {
> >          >              LOG.warn("Warning");
> >          >              warned = true;
> >          >           }
> >          >         }
> >          >     }
> >          >
> >          >     This is the only access to the variable 'warned', the
> >         value change is
> >          >     deliberately unsynchronized, and monotonic. Am I right to
> >         believe that:
> >          >
> >          >     * The first call WILL issue a warning.
> >          >     * Any thread will issue the warning AT MOST once.
> >          >     * Some (later) threads may not issue the warning, if the
> >         updated value
> >          >     is flushed to the heap and they load it?
> >          >
> >          >     Is there a better way to do this without sacrificing
> >         performance? Is
> >          >     this what the mysterious AtomicBoolean.lazySet, or even
> >          >     weakCompareAndSet is about?
> >          >
> >          >     This is right in the middle of something very concurrent
> >         which runs for
> >          >     a long time, so reducing overhead is far more important than
> >          >     occasionally issuing too many warnings.
> >          >
> >          >     Thank you.
> >          >
> >          >     S.
> >          >     _______________________________________________
> >          >     Concurrency-interest mailing list
> >          > Concurrency-interest at cs.oswego.edu
> >         <mailto:Concurrency-interest at cs.oswego.edu>
> >          >     <mailto:Concurrency-interest at cs.oswego.edu
> >         <mailto:Concurrency-interest at cs.oswego.edu>>
> >          > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >         <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> >          >
> >
> >
> >     _______________________________________________
> >     Concurrency-interest mailing list
> >     Concurrency-interest at cs.oswego.edu
> >     <mailto:Concurrency-interest at cs.oswego.edu>
> >     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> >
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list