I’m having trouble understanding the Kotlin/Native global immutability model, specifically for an iO...

# multiplatform

[Casey Brooks]

I’m having trouble understanding the Kotlin/Native global immutability model, specifically for an iOS/Android shared library. I basically want to do a one-time initialization on a singleton to register an API key, and the only way I could get the iOS tests to pass was by using @ThreadLocal on the companion object and @SharedImmutable on the value to be initialized once. But that @ThreadLocal annotation makes me think that another thread might try to access the shared object and have it not be there, does the @SharedImmutable mean that each thread-local companion object will reference the same API key after initialization? Here’s basically what I’ve got

class SingletonConfiguration
private constructor(
    val apiKey: String
) {

    @ThreadLocal
    companion object {
        @SharedImmutable
        lateinit var instance: SingletonConfiguration

        fun init(apiKey: String) : SingletonConfiguration {
            instance = SingletonConfiguration(apiKey)
            return instance
        }
    }
}

[Dominaezzz]

Hmm consider using AtomicReference and discard the @ThreadLocal.

[kpgalligan]

ThreadLocal does mean that each thread gets its own copy, but they’re mutable. SharedImmutable means all threads see that instance, but it’s “frozen”. I don’t know what will happen if you have a SharedImmutable as a field in a ThreadLocal

[kpgalligan]

Atomic ref would be a way to do this, but you should get a better understanding of what’s happening

[Dominaezzz]

It'll be frozen in each thread I think.

[kpgalligan]

https://medium.com/@kpgalligan/kotlin-native-stranger-threads-ep-1-1ccccdfe0c99

[kpgalligan]

It might be frozen for each thread, but hard to say. Not sure the runtime pays attention to those annotations after top level (though it might)

[Casey Brooks]

How can I use the AtomicReference? It doesn’t seem to be in the common stdlib, and I can’t seem to find documentation on a particular artifact I need to use for native

[kpgalligan]

In any case, you do need to dump that threadlocal if multiple threads need it

[kpgalligan]

Glad you asked…

[kpgalligan]

https://github.com/touchlab/Stately/blob/master/stately/src/commonMain/kotlin/co/touchlab/stately/concurrency/AtomicReference.kt

[kpgalligan]

Common code, does expect/actual to jvm and native

[kpgalligan]

“Live” example, if a bit complex: https://github.com/touchlab/DroidconKotlin/blob/master/sessionize/lib/src/commonMain/kotlin/co/touchlab/sessionize/AppContext.kt#L31

[Dominaezzz]

@kpgalligan Have you used kotlinx.atomicfu?

[kpgalligan]

Last time I checked although that complied for native, it didn’t actually work, but I haven’t looked in a bit (looking now…)

[kpgalligan]

Unless there’s serious magic, this would not work: https://github.com/Kotlin/kotlinx.atomicfu/blob/master/atomicfu/src/nativeMain/kotlin/kotlinx/atomicfu/AtomicFU.kt#L16

[kpgalligan]

Yeah…

[kpgalligan]

[kpgalligan]

Only supports single threads, which defeats the purpose (for what we’re doing)

[kpgalligan]

Before stately I had a fork of atomic fu working, but I figured I’d just stay out of that lane until that gets and update, and we’ll start deprecating stately features. That’s already happened to SharedImmutable and ThreadLocal. Those are available in common now

[Casey Brooks]

Finally got this working, Stately has helped greatly in using the AtomicReference. “Stranger Threads: Part 2” also really helped me understand this all better, in particular the sections about freezing objects and atomics. Thanks for the help, y’all!

[kpgalligan]

Sweet! There should be a part 3 on Threading explaining how to apply in multiplatform, but busy busy with the coding