Cycle consumption recording problem

[avi]

When I recorded the consumption of cycles, I found a very strange problem.
Motoko is a reactor model, should there be no concurrency problems? Or maybe it appears?

https://m7sm4-2iaaa-aaaab-qabra-cai.raw.ic0.app/?tag=3143301081

This is my demo code,
Execute after I deploy the code
If I click call once and wait for the result to execute, the result is what I want

But when I clicked it multiple times quickly, the result was the same as the picture.
There are fewer cycles before the execution of the loop than after the execution of the loop

[avi]

@nomeata @stephenandrews help me?

[avi]

When I use async await to get the data and hashmap to store the sh. A more amazing problem occurs, I can’t even get my cycles。

https://m7sm4-2iaaa-aaaab-qabra-cai.raw.ic0.app/?tag=3662302706

[stephenandrews]

Yeah await drops atomicity, so you need to handle that in your code

[avi]

https://m7sm4-2iaaa-aaaab-qabra-cai.raw.ic0.app/?tag=3143301081
This is my demo without async await

[peterparker]

@stephenandrews

Yeah await drops atomicity, so you need to handle that in your code

@avi yeah looks good I think if you move the demo’s await before Array.append

[avi]

I modified it, but it still appeared.

In my case, I quickly clicked call 10 times within 3 seconds.

[chenyan]

This is expected. You lose atomicity after await. So you cannot assume the global state is the same when the async calls reply back. See Joachim’s blog post about inter-canister calls.

[avi]

Is motoko not single threaded?

[avi]

[rossberg]

Atomicity is only guaranteed between awaits – otherwise an await could block your canister indefinitely. See this section of the manual (especially the warning box).