Double-check locking

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Double-check locking

JSR166 Concurrency mailing list
I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:

I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.

https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563

-blake

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
I'd be interested as well, especially in the Spin lock performance in Java. According to Aleksey Shipilev's well-known article
https://shipilev.net/blog/2014/safe-public-construction/
the  SafeDCLFactory performs best on x64 and ARMv7, but the article, although it mentions "exchanging the reference ... via the AtomicX classes"
actually does not contain a comparison with the Spin lock method. I guess the Java code would go like this:

private final AtomicReference<T> instance = new AtomicReference<>();

public T getInstance(Supplier<T> s) {
  while (true) {
    T v1 = instance.get();
    if (v1 != null) {
      return v1;
    }
    T v2 = s.get();
    if (instance.compareAndSet(null, v2)) {
      return v2;
    }
  }
}

(Aside: For the purpose of producing a singleton, I like this API (with the object factory  as a parameter to the getInstance() method) better than
spending another reference to hold the Supplier in a member.)

-- Sebastian

-----Original Message-----
From: Concurrency-interest [mailto:[hidden email]] On Behalf Of G. Blake Meike via Concurrency-interest
Sent: Monday, September 03, 2018 5:55 PM
To: [hidden email]
Subject: [Spam]: [concurrency-interest] Double-check locking

I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:

I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.

https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563

-blake

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Sanjay Brahmawar (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
Do you save anything by having a conditional?

It should work:

public T getInstance(Supplier<T> s) {
  T v1 = instance.get();
  if (v1 != null) return v1;
  instance.compareAndSet(null, s.get());
  return instance.get();
}

On the surface of it, you get an unnecessary read on a successful compareAndSet, but is that slower than a condition check?

Alex

> On 3 Sep 2018, at 20:03, Millies, Sebastian via Concurrency-interest <[hidden email]> wrote:
>
> I'd be interested as well, especially in the Spin lock performance in Java. According to Aleksey Shipilev's well-known article
> https://shipilev.net/blog/2014/safe-public-construction/
> the  SafeDCLFactory performs best on x64 and ARMv7, but the article, although it mentions "exchanging the reference ... via the AtomicX classes"
> actually does not contain a comparison with the Spin lock method. I guess the Java code would go like this:
>
> private final AtomicReference<T> instance = new AtomicReference<>();
>
> public T getInstance(Supplier<T> s) {
>  while (true) {
>    T v1 = instance.get();
>    if (v1 != null) {
>      return v1;
>    }
>    T v2 = s.get();
>    if (instance.compareAndSet(null, v2)) {
>      return v2;
>    }
>  }
> }
>
> (Aside: For the purpose of producing a singleton, I like this API (with the object factory  as a parameter to the getInstance() method) better than
> spending another reference to hold the Supplier in a member.)
>
> -- Sebastian
>
> -----Original Message-----
> From: Concurrency-interest [mailto:[hidden email]] On Behalf Of G. Blake Meike via Concurrency-interest
> Sent: Monday, September 03, 2018 5:55 PM
> To: [hidden email]
> Subject: [Spam]: [concurrency-interest] Double-check locking
>
> I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:
>
> I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.
>
> https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563
>
> -blake
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Sanjay Brahmawar (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
This looks like a copy-paste typo:

      if (v1 === newVal) {
        return v2
      }

... which looks like a trick preparing us to buy some Kotlin-style syntactic sugar:


class DoubleCheckedLocking () {
    @Volatile private var field : Int? = null

    private final val lock = Object()

    fun lazyGet() : Int = field ?:
        synchronized (lock) { field ?: computeValue().also { field = it } }

    fun computeValue() : Int { return 42 }
}

fun main(args: Array<String>) {
     DoubleCheckedLocking().let {
        println(it.lazyGet())
        println(it.lazyGet())
    }


very concise, but still rather tricky (trickier? than plain java)


On Mon, Sep 3, 2018 at 8:55 AM, G. Blake Meike via Concurrency-interest <[hidden email]> wrote:
I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:

I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.

https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563

-blake

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
What is testAndSet?

Did you read
The Internet Elves have recently updated it.
Should you add a Kotlin section?

Why haven't the Kotlin folk added even sweeter syntactic sugar to lazy-once-init a field?


On Mon, Sep 3, 2018 at 4:12 PM, Martin Buchholz <[hidden email]> wrote:
This looks like a copy-paste typo:

      if (v1 === newVal) {
        return v2
      }

... which looks like a trick preparing us to buy some Kotlin-style syntactic sugar:


class DoubleCheckedLocking () {
    @Volatile private var field : Int? = null

    private final val lock = Object()

    fun lazyGet() : Int = field ?:
        synchronized (lock) { field ?: computeValue().also { field = it } }

    fun computeValue() : Int { return 42 }
}

fun main(args: Array<String>) {
     DoubleCheckedLocking().let {
        println(it.lazyGet())
        println(it.lazyGet())
    }


very concise, but still rather tricky (trickier? than plain java)


On Mon, Sep 3, 2018 at 8:55 AM, G. Blake Meike via Concurrency-interest <[hidden email]> wrote:
I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:

I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.

https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563

-blake

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list

On Sep 3, 2018, at 16:12, Martin Buchholz <[hidden email]> wrote:

> This looks like a copy-paste typo:
>
>       if (v1 === newVal) {
>         return v2
>       }

It is.

> On Sep 3, 2018, at 16:20, Martin Buchholz <[hidden email]> wrote:
>
> What is testAndSet?

Jebuz, Martin.  I cannot believe neither I nor any of the other people that read this, have noticed either of those two glaring bugs in the text.  I certainly owe you a beer.

> Did you read
> https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java
> The Internet Elves have recently updated it.
> Should you add a Kotlin section?

Yes.  Will do.  Thanks.

-blake
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
It's a pet peeve of mine when double checked locking code reads the volatile field more times than necessary.  The programmer should introduce locals (unless they're lucky enough to be programming in kotlin).  (Fix DoubleCheckedProvider)

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Double-check locking

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
Your section labelled "Spin Test"  is not quite lazy (I didn't read the whole article, but I didn't see mention of it.)   For example, if the line:

val v2 = provider.get()

has side effects (such as initiating a database connection, or opening a file), then you could still have two threads succeed.  


On Mon, Sep 3, 2018 at 9:02 AM G. Blake Meike via Concurrency-interest <[hidden email]> wrote:
I beg your indulgence: I realize that this post is quite off-topic.  It is, none the less, something that I think that people on this list might find of interest:

I’ve done some empirical testing of the behaviors of a couple of lazy initialization idioms. While this experiment is entirely on an Android runtime, I would be interested in re-running it on a JVM.

https://medium.com/@blake.meike/fast-locking-in-android-with-kotlin-5de656351563

-blake

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest