Is using

AtomicRef

and

Deferred

a good approach to ensure that concurrent calls to

update()

never cause more than one

updateAsync()

execution in parallel? For example let’s say

updateAsync()

execution takes 10 seconds and there are 4 calls to

update()

with 2 seconds in between.

updateAsync()

would only be called once and they all share the same result, right?

The code you have might call

updateAsync()

multiple times. (Unless it's just an illustration then nvm). The function pass to

updateAndGet

should be pure.

What do you mean by pure?

Without side effect. As the lambda could be executed multiple times.

Oh, really. Damn. It launches a coroutine 😅

Haha yeah. You could have 8 `updateAsync()`s running concurrently without it's result being consumed.

I guess I have to fall back to a

Mutex

then?

Mutex

basically seems to be a

Semaphore

with

permits = 1

, doesn’t it?

It is but

Semaphore

was quite recently optimised and currently performs better than

Mutex

. (I checked this a month ago, not sure if

Mutex

has been updated since).

Interesting. Thanks for the heads ups 🙂

What’s the intention here? Is it that if

updateAsync

is running that it won’t try to update again? Or that new updates cancel/replace the previous one? There are a handful of things you can do with Channels or Flows that can solve both those cases pretty elegantly

New update requests should join the current pending update. I’ve already rewritten it as a Flow 🙂

If you've got time or can be bothered. Can you share the rewrite? I can't imagine how this can be rewritten with a

Flow

.

It’s merged with other functionality by now, esp. caching. So the behavior has changed slightly which makes it work with Flows 🙂

Ah,

stateIn

off course, that makes a lot of sense.