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