Hey, guys. Is there multiplatform `lock` or `synchronized` in Kotlin? <https://stackoverflow.com/que...

# multiplatform

[4ntoine]

Hey, guys. Is there multiplatform lock or synchronized in Kotlin? https://stackoverflow.com/questions/56882860/is-there-multiplatform-lock-on-kotlin

[thana]

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/-mutex/lock.html

[4ntoine]

afaik coroutines library increases disk fooprint so it’s undesired. Anything else?

[elizarov]

There’s nothing else yet, but is planned as a part of kotlinx.atomicfu library. Btw, what kind of “disk footprint” are you measuring?

[4ntoine]

Hi, Roman. I’m talking about jar size ~ 1.3Mb https://mvnrepository.com/artifact/org.jetbrains.kotlinx/kotlinx-coroutines-core/1.3.0-M2 looks a bit scary

[elizarov]

Are you using any kind of optimizer? ProGuard, R8?

[4ntoine]

We’re working on some library (currently android-only) and it’s undesired to add heavy deps without serious reason. We do understand our partners that are using it in end-user apps can use Proguard and shrink unused, but first i want to investigate alternatives

[4ntoine]

Any estimation on when synchronized will be removed from common lib? Are we safe to use it for some time at least?

[elizarov]

If you are writing Android/JVM lib you can just use synchronized. It is a part of a stable Kotlin API and there is no plan to remove it.

[4ntoine]

We’re writing multiplatform library, but the only implementation for now (that is going to be released for production) is JVM/Android. So ideally we would use some multiplatform approach that will not be obsolete soon. For now it works for us with synchronized, but looking for long-time (or just “proper”) solution

[4ntoine]

What disk footprint can we expect when shrinked with Proguard/r8 if using this mutex lock from coroutines core lib only?

[elizarov]

Right now coroutines add ~150kb in debug mode (full symbols) and we’re looking to get it below < 100kb by turning off various debug & high-scale features. I don’t know how much that would translate with obfuscation and stripped debug data.

[elizarov]

Note, though, that Mutex only works if you are using coroutines — it is a lock that suspends a coroutine, not blocks a thread.

[gildor]

One more reason to extract channels or/and flow API from core (yes I again talking about this). Or even more fine grained splitting

[4ntoine]

@elizarov Could you please explain how you measured 150Kb for kotlinx coroutines, is it jar size? Not sure how 150kb and 1.3Mb correlates.. Sounds great

[elizarov]

It depends on what features you use. Many of them (like channels, flows) are incremental — you only get them if you use them (optimizers remove unused code)

[4ntoine]

oh, it’s size after shrinking. Thanks for clarification

[elizarov]

(but w/o obsufcation. It will be much smaller then)

[louiscad]

Would be interesting to know after obfuscation as shrinking something like kotlinx.coroutines.channels.Channel can become 5 times smaller in terms of characters count: a.a.a.a, and so does all the bytecode.

[basher]

Stately has a mpp lock https://github.com/touchlab/stately

[4ntoine]

@basher Looks promising, thanks for the link

[elizarov]

Spinlock-only impl on native 😞

[basher]

Spinlock on mingw. NSRecursiveLock on iOS. I think @kpgalligan might be looking at refactoring so that locks have to be closed; then they can use pthread_lock. Issue right now is that the current implementation relies on iOS and JVM objects being able to tie in to object lifetime automatically (I.e. destroy resources when objects are collected). Can't do that on other platforms, so everything else gets a spinlock for now.

[kpgalligan]

I’m in process on that update. The lock is less of an issue that I rewrote the collections to use C++ collections directly rather than native atomics, but the “relaxed mode” commits on native have kind of put stately rewrites on the back burner, TBH. However, yes, the plan is to add a close and use pthread_lock on all native. More like this

[kpgalligan]

expect class Lock() {
fun lock()
fun unlock()
fun tryLock(): Boolean
fun close()
}

[kpgalligan]

Reaktive does this: https://github.com/badoo/Reaktive/blob/master/reaktive/src/commonMain/kotlin/com/badoo/reaktive/utils/Lock.kt, https://github.com/badoo/Reaktive/blob/master/reaktive/src/nativeCommonMain/kotlin/com/badoo/reaktive/utils/Lock.kt

[kpgalligan]

Spinlock, yeah. That darn windows. Maybe a less ambitious stately update in the near term, or pull collections out into a separate lib (that actually sounds like a good idea)

[kpgalligan]

Moved. Collections now a separate module. Native lock collapsed so all instances use pthread and need ‘close’ called. Still a WIP, but simpler build for sure (and need to deploy windows): https://github.com/touchlab/Stately/blob/master/stately/src/nativeCommonMain/kotlin/co/touchlab/stately/concurrency/Lock.kt

[Arkadii Ivanov]

@kpgalligan perhaps arena, attr and mutex fields should be private as they are implementation details 😀

[kpgalligan]

Like I said, work in progress. The issue is doing close as an extension. The idea is I want to see if we use typealias for expect/actual, can we make the library be invisible to one side. In this case the JVM. I assume that will also take some proguard to strip the unnecessary definitions.

[kpgalligan]

On the lock, the JVM has no close, so adding that to Lock means I can no longer use typealias

[kpgalligan]

The libraries I’m building have a strong native mobile and Android lean to them, so if I can, I want to impact the JVM side minimally.

[kpgalligan]

If typealias doesn’t make the JVM side invisible, or maybe if it’s not worth it, I’d move close to Lock, then yes, the rest would be internal (or hide them a different way)

[kpgalligan]

(sort of) fixed it

[Arkadii Ivanov]

Looks better)