What's the best option for controlling shared muta...

# multiplatform

[serebit]

What's the best option for controlling shared mutable state in common code? I have a cache that can be accessed and updated by multiple coroutines (on JVM, anyway). Actors are unavailable on native, so should I go with a Mutex approach, or make the cache an AtomicReference?

[Arkadii Ivanov]

Mutex won't help as you can't share mutable state across threads, even if access is properly synchronized. Go with AtomicReferenc + freeze + immutable structures.

[basher]

stately has frozen mutable structures

[kpgalligan]

https://github.com/touchlab/Stately

[kpgalligan]

You can also keep all of your data in a single thread, by way of a worker, and communicate through messages. It feels like a weird way to do it, but it’ll work

[kpgalligan]

Stately collections work, but pending the outcome of relaxed mode, they need a rewrite. Performance is so so

[serebit]

Could I have the cache be thread-local and contain mutable data, and have other threads communicate with it via messages with immutable data? I'm not very familiar with the memory model of native.

[kpgalligan]

Yeah, that’s essentially what I’m proposing. You can keep frozen data in a non-frozen container. That’s not going to be an issue. Just don’t freeze the container :-)

[serebit]

I also know that threading behavior of coroutines in K/N is going to be revamped significantly in the coming months, so I'm more concerned with race conditions on JVM than with threading on Native, at least for now.

[serebit]

That reminds me, is data frozen by default when crossing threads, or do I have to freeze it myself? Because having to freeze it myself would make writing this system in common code a lot more difficult.

[kpgalligan]

Valid concern

[basher]

you have to freeze it yourself (.freeze())

[Arkadii Ivanov]

But you can freeze it inside your cache class. So clients won't care about it.

[kpgalligan]

"That reminds me, is data frozen by default when crossing threads, or do I have to freeze it myself? Because having to freeze it myself would make writing this system in common code a lot more difficult." Not with stately! There's a common definition for freeze that is a noop on jvm and js

[serebit]

Cool (no pun intended). Thanks for the info!

[Kris Wong]

have you seen calling freeze on an object deadlock?

[kpgalligan]

No?

[kpgalligan]

Crash or just stop?

[Kris Wong]

i guess that makes me special 😛

[kpgalligan]

Example?

[Kris Wong]

well, in unit tests it appears to be crashing. from an iOS app unit test it's getting stuck.

[Kris Wong]

so, both

[kpgalligan]

Do you have a public example? I’ve been doing this for a while and have never seen that. I think a lot of people would be very interested in seeing that happen

[Kris Wong]

unfortunately I do not

[kpgalligan]

Can you write an example of a block of code you think is deadlocking? I will try it now. Is it always, or just sometimes?

[Kris Wong]

always.

[basher]

are you calling it on a background thread not managed by K/N?

[basher]

i could see something weird happening if you forgot to initRuntimeIfNeeded()

[kpgalligan]

I mean, I’ve never seen this, and have done quite a bit of both testing and calling freeze.

[kpgalligan]

An example piece of code would be helpful

[Kris Wong]

could be, XCTest is managing the threads. let me explore a little more in the debugger

[Kris Wong]

no, it's the main thread

[Kris Wong]

I added a method to a class, makeImmutable, which just calls freeze. unfortunately I can't step into that.

[Kris Wong]

let me try App Code

[kpgalligan]

https://github.com/touchlab/xcode-kotlin

[kpgalligan]

Kotlin xcode plugin

[serebit]

This isn't really related to my original post, can you guys move this to a new thread?

[basher]

Can just DM Kevin, and I'll find out what happened later 🙂

[Kris Wong]

hah