[concurrency-interest] Unsynchronized lazy conditions

Yuval Shavit yankee.sierra at gmail.com
Thu May 31 23:13:19 EDT 2018


I think the key word is "immediately." If the initialization happened far
before (ie, that converse case you mentioned), then it wouldn't be
immediately before.

On Thu, May 31, 2018, 8:33 PM David Holmes <davidcholmes at aapt.net.au> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180531/63c104c8/attachment-0001.html>


More information about the Concurrency-interest mailing list