Better Support for new MM

[dcvz]

Since we are using the new KMM memory model - this PR improves things:

• moves away from IsoMutableMap (as sharing between threads is no longer an issue)
• replaces stately (only used for atomics/locks now) with atomic-fu (made by kotlin team)

Addresses #16

Note:
I attempted to keep support for both memory models, but the flag is only available at the kotlin.native level and supporting it would've created a lot of boilerplate code in the project just to expose the flag to common.

Ktor in their latest release dropped support for the old memory model, so I think it's a safe option to as well.

[dcvz]

@ychescale9 this is now ready for review!

[ychescale9]

Great work! Just left a couple of comments 😃

[ychescale9]

Should we use update(function: (T) -> T) instead?

It would also address this from the atomicfu dos and don'ts:

Do not introduce complex data flow in parameters to atomic variable operations, i.e. top.value = complex_expression and top.compareAndSet(cur, complex_expression) are not supported (more specifically, complex_expression should not have branches in its compiled representation). Extract complex_expression into a variable when needed.

[ychescale9]

these aren't complex expression but perhaps we can also use update(function: (T) -> T) just in case.

[dcvz]

@ychescale9 addressed PR comments!

[dcvz]

If this gets merged it'll be interesting to see if #9 is still an issue.

[ychescale9]

Thanks!

[ychescale9]

moves away from IsoMutableMap (as sharing between threads is no longer an issue)

@dcvz do you have any insights on why sharing between threads is no longer an issue? AFAICT the implementation is no longer thread-safe as MutableMap isn't thread-safe and we're not putting all the operations behind a reentrantLock.
Wonder if we should revert back to Stately's IsoMutableMap for now?

[dcvz]

do you have any insights on why sharing between threads is no longer an issue? AFAICT the implementation is no longer thread-safe as MutableMap isn't thread-safe

@ychescale9 The IsoMutableMap put the map behind an isolated state, so you could use it from any thread without running into the common freezing issues in iOS -- but it made access expensive. In the new memory model there's no longer freezing and no requirement that mutable state must always be accessed from the same thread.

and we're not putting all the operations behind a reentrantLock

I think that's a different concern.. You're talking about having a "ConcurrentMap" -- which would make concurrent access safe. There's some implementations out there of one, but I don't think we necessarily need one. Currently the only thing we'd need to make concurrently safe is the get(loader:) given that we don't want two concurrent operations to make the possibly expensive operation of loading (we already do this).. But the normal get and put do not suffer from this.. you might get right as you put and get null since the value is not set yet, but I think that should be fine.

[ychescale9]

My original jvm only implementation used ConcurrentHashMap which allowed thread-safe concurrent access so I thought this might be a bit of downgrade for jvm users.

The AndroidX collection library is being migrated to KMP https://android-review.googlesource.com/c/platform/frameworks/support/+/2070948 and it's using a lock to guard all operations. It's probably not as efficient as ConcurrentHashMap but could be a quick win to support thread safe concurrent access until there's a good multiplatform thread-safe concurrent map implementation.