Are there any map synchronization primitives avail...
# multiplatform
m
Are there any map synchronization primitives available for kotlin multiplatform?
a
Or just use normal immutable map plus atomic reference
k
Well, you can’t if you need to change it because it needs to be frozen. If it’s a read-mostly, it won’t be so bad. Alternative would be a map structure that is only visible on one thread and you communicate by way of thread messages
a
What you mean? AtomicReference<Map<x,y>> works just fine. You copy the map, freeze it and put back to the AtomicReference. And you can do it atomically.
Immutable, not mutable of course
k
That technically works, but like I said, it makes sense if you’re “read-mostly”. If you’re using a map because you want a “hash map”, you’ll be in for a disappointment. Writing in a hashmap is O(1). Copying the whole map, mutating it, then freezing it, is O(N). It’ll get ugly fast as it grows.
There are uses where that makes sense. Fixed size caches, read mostly stuff.
a
Exactly, which means that it's actually possible. If one has performance impact then we need kinda persistent collections with Log N read write.
k
What’s actually possible? Frozen collections? Hash map is constant time, first of all, second, stately hash map, while slow mechanically compared to regular mutable hash map does have constant time operations . I’m not sure what you’re arguing
I did notice early on reviewing Reaktive that you freeze and modify collections. That’s a situation where presumably you don’t modify it much, so that strategy is OK, but I would imagine most would not consider that a good general purpose solution. It’s an artifact of how native works (currently) but isn’t “good” https://github.com/badoo/Reaktive/blob/master/reaktive/src/commonMain/kotlin/com/badoo/reaktive/subject/DefaultSubject.kt#L12
a
I'm not arguing at all) just telling that normal immutable map might work as well unless there's any performance impact.
Yep, we'll improve performance where needed.
k
Oh, sure, can you freeze whole collections? Of course.
My hedging didn’t post. Stately collections “work”, but they are mechanically quite slow, and are pretty high on the “to change” list. The hash map is a real “hash map”, but you won’t see much benefit over copy/freeze until you get into sizes where the O(1) vs O(N) really maifest. I’m waiting on “relaxed mode” a bit to explore updates, because depending on how that goes, the problem is likely to change quite a bit.
a
Well we would love to use stately, but that time there were no binary artifacts mentioned on GitHub and it was stated like not production ready. Now it looks ok, will consider it again) thanks
k
Oh, my docs are crap. That is true. I use it a lot, but I’ve been focused elsewhere and haven’t updated them.
I’m used to most of my published libraries being super niche, or me contributing to other projects. I’ve been very lazy around managing my own.