I often find myself having to load a global resource asynchronously, where it only needs to be loaded once, but it could potentially fail. An example is the delta with the server time, so that I can implement an NTP. For those cases, I implemented a

DeferredCache

with an

await

method which when called: - if no coroutine to load the resource has been launched, it starts a new one - if a coroutine to load the resource has finished successfully, it returns its result - if a coroutine to load the the resource has finished with an error, it restarts a new one - if a coroutine to load the resource has been launched and is still active, it awaits its result My current implementation looks like this

class DeferredCache<T: Any>(
    private val coroutineScope: CoroutineScope = GlobalScope,
    private val block: suspend CoroutineScope.() -> T
) {
    private var deferredValue: Deferred<T>? = null
    private val deferredValueLock = Mutex()

    private val usableDeferredValue: Deferred<T>?
        get() = deferredValue?.takeUnless { it.isCompletedExceptionally }

    suspend fun await(): T {
        val deferredValue = usableDeferredValue ?: deferredValueLock.withLock {
            usableDeferredValue ?: coroutineScope.async(NonCancellable, block = block).also { deferredValue = it }
        }
        return deferredValue.await()
    }
}

Can you think of a more optimal solution? Anyone running into this scenario as well? Might it be worth adding a “standard” way to do this?

We do something similar (expect we have an unbounded number of them built on a ConcurrentMap). I can see the use case for a suspendable lazy but anything more than that and you get into details that are heavily domain specific. ie. what to do on an error, how long do you cache the error, how long do you cache the result etc.

Question: Shouldn't

deferredValue

be

@Volatile

?

It’s not so much the lazy aspect which is important (because that’s supported by the

coroutineStart

parameter in coroutine builder functions), but it’s rather the “auto-restart” aspect which is missing from the framework.

@Martin Devillers Are you sure?

deferredValue

may be accessed from any thread and is not accessed using JVM monitor synchronization. So what one thread writes, another doesn't necessarily have to see, from my understanding.

@cbruegg If a thread sees

null

in

deferredValue

it proceeds to take the lock in which case it should get the updated value (ie. I dont see a problem)

@spand The thing is that it's not a JVM lock, but one implemented using coroutines, so there's no happens-before barrier. Though I might also be misunderstanding. See https://stackoverflow.com/a/3519736/1502352

I assume the

withLock

establishes the happens before relation. It javadoc says:

JVM API note:
 * Memory semantic of the [Mutex] is similar to `synchronized` block on JVM:
 * An unlock on a [Mutex] happens-before every subsequent successful lock on that [Mutex].
 * Unsuccessful call to [tryLock] do not have any memory effects.

Oh, that's interesting, thanks! I didn't know that.

@Martin Devillers The restart logic is still quite domain specific (because it is bad in general) in that it will probably hammer a service if it is already struggling.

Good point, it could be configurable with a restart policy though. I ask the question because I’m curious to see whether it’s a common enough problem to warrant a common solution.

Maybe. In the general case however it quickly extends to using stuff like the circuit breaker and bulkhead patterns

👍

Not saying there isnt a good middle road that could be taken 😉

You can do much simpler. Class is not needed. Just write a function and use `async(start = LAZY)`: https://gist.github.com/elizarov/d16664152fa65f6bd794319a5b1ed9ab

It’s not quite the same. In my implementation, when awaiting the value, if the request fails then the error is thrown and there isn’t another request started immediately. Another request will only be started when

await

is called again.

Ah. I see.