Using ConcurrentHashMap can block a thread corouti...

# coroutines

[v0ldem0rt]

Using ConcurrentHashMap can block a thread coroutine is running on

[Vsevolod Tolstopyatov [JB]]

it’s true, but probability of blocking is very low.
If you for some reason care about blocking, you can use lock-free hash map (e.g. one from JCTools library). If you care about general utilization, it’s ok to use CHM

[v0ldem0rt]

JCTools looks awesome. Can help us with more data structures

[groostav]

another solution is kotlinx.collections.immutable and kotlinx.coroutines...Mutex, those two in conjunction should could you pretty straight-forward concurrency.

[groostav]

i should say, on our team, I've had a couple accidents from our devs mixing and matching java.util.concurrent packages with kotlinx.coroutines ones, needless to say the results can be pretty strange deadlock. As a result I've put in place a "one or the other" rule, where we simply fobid mixing and matching those two packages

[v0ldem0rt]

that's what my second question was, I've implemented a class called SuspendableMap that uses the Mutex and wraps the standard map to make it work.

[Vsevolod Tolstopyatov [JB]]

Be careful with it.
CHM is extremely performant (since Java 8 ), most likely SuspendableMap will be visibly slower.
Usually it’s not worth to implement your own primitives instead of [well-tested and polished by years] already implemented ones even if there is a small probability of blocking. It’s worth doing after measuring and understanding that CHM is actually a bottleneck (which is unlikely true for an average application)