Kotlin Native concurrent mutable state post series Surprisin

Question

Kotlin Native concurrent mutable state post series Surprisingly productive Sunday <https dev to touchlab kotlin native transferring state 4n8i>

Dominaezzz · Answer

About keeping a `MutableMap` in a `DetachedObjectGraph` have you considered using `DetachedObjectGraph TransferMode UNSAFE ` when recreating the `DetachedObjectGraph` You could even use `DetachedObjectGraph TransferMode SAFE ` to limit the graph checks on the individual elements

Dominaezzz · Answer

Actually this seems interesting I ll try implementing this myself

kpgalligan · Answer

You could but I stay away from all UNSAFE usage It always ends in tears For me at least

kpgalligan · Answer

I would double down on that thinking if publishing a library

Dominaezzz · Answer

I can imagine I ve already hit a wall can you have frozen objects in a `DetachedObjectGraph`

kpgalligan · Answer

Yes

Dominaezzz · Answer

Also do `DetachedObjectGraph` have to be explicitly released

kpgalligan · Answer

Yes

Dominaezzz · Answer

Does the frozen object have to be detached too

Dominaezzz · Answer

Nahh that s a silly question but I feel it shouldn t haaaaaave to be

kpgalligan · Answer

Yes Detaching creates a +1 on the ref count

Dominaezzz · Answer

Oh

kpgalligan · Answer

I think On phone having dinner drinks so all of my messages are questionable at this poit

kpgalligan · Answer

Point

kpgalligan · Answer

Been thinking about this more The value in UNSAFE would presumably be not checking the whole object graph It s risky but may be useful in some situations You can also mark it shared under the hood but I wouldn t recommend that either Until I need something that performs better I ll be focused on the thread confined state In the past anytime I try to work around the concurrency rules I wind up with a race condition that s very difficult to diagnose

Dominaezzz · Answer

I ve written up an implementation Although it s slightly different from what I described <https github com Dominaezzz FrozenStructures blob master src main kotlin DetachedMutableMap kt>

Dominaezzz · Answer

It basically keeps frozen keys and values in `StableRef`s this way the `MutableMap` can stay completely detached

Dominaezzz · Answer

Too tired sleepy to tidy fix up the locking Will continue tomorrow

kpgalligan · Answer

I m going to look at it but the unsafe is definitely freaking me out I had an issue even using safe that I still haven t figured out but since I m not really using `DetachedObjectGraph` for anything besides a comparison benchmark I didn t dig too deep

kpgalligan · Answer

Get anywhere with this I ran it on mac and `testBasicThreads` has errors that look like memory related race conditions ``` RUN DetachedMapTest testInitFrozen OK DetachedMapTest testInitFrozen 0 ms RUN DetachedMapTest testBasicThreads basic threads time 1 23ms kotlin AssertionError Expected lt 62 gt actual lt 1850 gt Users teamcity3 buildAgent work 4d622a065c544371 runtime src main cpp Memory cpp 1091 runtime assert Must be positive Abort trap 6 Kevins MacBook Pro 5 FrozenStructures kgalligan$ ```

Dominaezzz · Answer

Yeah I fixed it and pushed it The issue was that I forgot to wait for the workers to finish after terminating them I don t use workers very much

Dominaezzz · Answer

That runtime assert though I think the Kotlin runtime doesn t wait for all Workers to finish before terminating like the JVM

Dominaezzz · Answer

But that s a different issue

kpgalligan · Answer

``` RUN DetachedMapTest testInitFrozen OK DetachedMapTest testInitFrozen 0 ms RUN DetachedMapTest testBasicThreads basic threads time 160ms kotlin AssertionError Expected lt 1881 gt actual lt 1850 gt Users teamcity3 buildAgent work 4d622a065c544371 runtime src main cpp Memory cpp 1091 runtime assert Must be positive Illegal instruction 4```

kpgalligan · Answer

I would not assume `Memory cpp` asserts are benign Also the actual count check is wrong obviously Not sure which check that is though

Dominaezzz · Answer

Hmm I ll try and look into that Can t reproduce on my Linux setup

kpgalligan · Answer

Is Linux in a VM Totally speculating but if VM it might only run on one core

Dominaezzz · Answer

Nope I run in directly on my computer

Dominaezzz · Answer

I figured out the issues The single threaded tests failed because iterators create cyclic garbage solved by calling `GC collect ` before detaching The multi threaded test failed because `waitForMultipleFutures workers map it requestTermination 5000 ` only waits for a single future very misleading name So waiting for the workers manually fixes the race condition in the test

Dominaezzz · Answer

I ll push the changes soon