Re: Lazy, cached supplier: most performant mutex mechanism?

I believe double-checked locking, such as Martin's version in Guava
Suppliers#memoize
<https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Suppliers.java#L124-L137>,
is the best approach on the JVM for instance-level memoization.

On Fri, Jul 31, 2020 at 10:42 AM Ghadi Shayban via Concurrency-interest <
[email protected]> wrote:

> This seems like it would be a common stdlib ask, but what is the most
> performant way to protect the code inside a supplier from being
> concurrently realized more than once? Contention would be rare, and the
> losing threads need to wait on the value being computed by the winning
> thread.
>
> The most straightforward thing to do is a synchronized block, but this
> currently pins a carrier thread in Project Loom.
>
> The Supplier needs to keep track of:
> 1) the thunk, if unrealized
> 2) a value, if realized
>
> Golang's sync.Once does this [1] (CAS, fallback to mutex. Doesn't remember
> value)
> Clojure's lazy sequences use synchronized [2]
>
> Is there a better way to approach this on the JVM?
>
> Thanks!
>
> [1] https://golang.org/src/sync/once.go
> [2]
> https://github.com/clojure/clojure/blob/30a36cbe0ef936e57ddba238b7fa6d58ee1cbdce/src/jvm/clojure/lang/LazySeq.java#L39-L46
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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