Hello everyone, Since Multithreaded coroutines a t...

# multiplatform

[Osman Saral]

Hello everyone, Since Multithreaded coroutines a thing now, do we need to use stately (or freeze state in general)? Documentation points against it, says The concurrency libraries mentioned here will freeze your data automatically. I'm using KaMPKit to get used to things, even if it uses multithreaded coroutines, stately is also used. So I'm really confused 😕 some concurrency concepts are hard for me to understand, should I really dive into those and try to learn as a KMM beginner?

[Nicklas Jensen]

You don’t need Stately do use multithreaded coroutines in Kotlin Multiplatform. You will need to get a good grasp on the concurrency model of Kotlin/Native, of which the tricky part essentially is:

Given multiple threads, when an object (instance of a class) is referenced from code executing on another thread from what it was created on, that object will automatically become frozen. A frozen object is immutable and thus can no longer be mutated (e.g. calling .add() on a MutableList<T>, or setting a property on the object) for the lifetime of the process/application, nor can any objects referenced by the frozen object, as those too will become frozen. Attempting to mutate a frozen object will throw an exception.

As to whether you need to dive into them and learn as a KMM beginner - it depends on the type of application you’re looking to build while learning 🙂

[Osman Saral]

It wasn't that hard actually, thank you 🙂 so my question is, will native-mt branch of coroutines prevent the exception? or should I use ensureNeverFrozen to be sure about the freeze state?

[Nicklas Jensen]

The native-mt branch does not prevent freezing of objects by itself, nor does it prevent the exception when attempting to mutate a frozen object. You don’t need ensureNeverFrozen() (my team doesn’t use it at all). If your object is frozen (as the result of it being referenced by code executing on another thread), an exception will be thrown as soon as any part of your code attempts to mutate it, though any and all threads are allowed to read it at any given time. If you do need mutable shared state you can use an AtomicReference (e.g. from Stately), but you could also use some kind of event/message queue (e.g. the Main dispatcher) for all reads and writes of the state, effectively limiting all access to the state to a single thread.

[Nicklas Jensen]

It’s also worth noting that the Kotlin team at JetBrains are working on a new Kotlin/Native memory model that should enable mutable state shared across threads. There was a recent blog post about it, which Siggi has posted below 👇

[Siggi Gunnarss]

https://blog.jetbrains.com/kotlin/2021/05/kotlin-native-memory-management-update/

[Osman Saral]

thank you all 🙂 I wish @kpgalligan also made a comment, since he brought me here with his great Stranger Threads articles 🙂

[Osman Saral]

and KaMPKit ofcourse

[kpgalligan]

The memory model update won't be until well into next year, I would guess. You don't need stately for anything, but there are multiple modules available. We're using "stately-common" in KaMP Kit, which is just a bunch of concurrency related definitions for common code. While you don't need ensureNeverFrozen, you definitely need to understand it, or you'll have a crap time debugging issues later. We use it for "View Model" level state in common code, as we're very intentional about what is and is not frozen.

If your object is frozen (as the result of it being referenced by code executing on another thread), an exception will be thrown as soon as any part of your code attempts to mutate it,

True. What you don't know (in complex cases) is how it was frozen, and when, which you need to know to debug the problem. That's what ensureNeverFrozen is for. You can just add that when debugging, but we use it on certain classes all the time, to ensure it's doing what we expect as development continues, especially with larger teams, or as devs new to KMP are contributing to the project. I will mistakenly freeze objects sometimes too, though. It's it easy to do by mistake.

[kpgalligan]

As for Stately, after the new memory model, I would assume it won't be super useful, but we'll see. I already soft-deprecated it once when the native team was working on the relaxed memory model in 2019 (2018?). However, as a quick tool for collections, thread isolated state, atomics, locks, etc. It's useful.