You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I must admit that I am having some trouble following the implementation of the native SynchronizedObject / ReintrantLock actual:
NativeMutexNode does not seem to be documented at all in the shared native source code. So I'd guess it behaves like a posix lock, but if I look at the Android impl, it seems to do extra stuff. Wouldn't it make sense to document the expected behavior in NativeMutexNode, in particular if/where/how it differs from posix behavior? It looks like a non-reintrant lock that blocks when called from the same thread again (instead of causing an error in the posix case), is that correct? If would be nice if the expected behavior would be more explicit in the code.
The while loops look like they only "loop" immediately (without blocking) where compareAndSet is unsuccessful, so there is no active waiting / spinning. It might make sense to make this more explicit in the documentation
If private val mutexes is only accessed in init, could it be local to init instead of being a field?
What's the advantage of an initial capacity if the available locks form a linked list? Could this just be obsolete leftovers from a previous array-based pool?
The text was updated successfully, but these errors were encountered:
I must admit that I am having some trouble following the implementation of the native SynchronizedObject / ReintrantLock actual:
NativeMutexNode does not seem to be documented at all in the shared native source code. So I'd guess it behaves like a posix lock, but if I look at the Android impl, it seems to do extra stuff. Wouldn't it make sense to document the expected behavior in NativeMutexNode, in particular if/where/how it differs from posix behavior? It looks like a non-reintrant lock that blocks when called from the same thread again (instead of causing an error in the posix case), is that correct? If would be nice if the expected behavior would be more explicit in the code.
The while loops look like they only "loop" immediately (without blocking) where compareAndSet is unsuccessful, so there is no active waiting / spinning. It might make sense to make this more explicit in the documentation
If
private val mutexes
is only accessed in init, could it be local to init instead of being a field?What's the advantage of an initial capacity if the available locks form a linked list? Could this just be obsolete leftovers from a previous array-based pool?
The text was updated successfully, but these errors were encountered: