Lazy, cached supplier: most performant mutex mechanism?

Ghadi Shayban via Concurrency-interest <[email protected]> Fri, 31 Jul 2020 13:40:21 -0400
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <CAO3q7t9XOZbBr=Mp_z5FmVX7ff4=2J6yAevVat-iiFW6Kji4Eg@mail.gmail.com>
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