Add Mutex.holdsLock

[fvasco]

No description provided.

[elizarov]

Have you considered following the pattern of Thread.holdLock(). That is, instead of providing checkLockOwner method, provide a more general isLockOwner method (or maybe call it holdsLock), and let client code be written as check(lock.holdsLock(owner))?

[elizarov]

Also, since the implementation is not straightforward, a test for this method's operation in different circumstances is needed, too (you can add it to MutexTest)

[fvasco]

Have you considered following the pattern of Thread.holdLock()

Yes, I did, this is an interesting question.

Thread.holdLock() is specific indeed for debugging purpose in conjunction with assert keyword. Unfortunately Kotlin doesn't provides an adeguate replacement so, in my initial choice, I preferred to not expose any debug information and to provide only the required functionality.

However the holdLock is clearly more versatile, if you consider it preferreable then I apply the change.

In order to cover all use case, in your opinion what are the useful use cases??

[elizarov]

I don't have any specific use-cases for holdsLock beyond debugging via check(lock.holdsLock(owner)). It just looks more explicit to use it as a part of check(...) expression that I use for my preconditions, than a method named with check.

[fvasco]

To debugging purpose we should consider to provide an inspection method to understand "what" locks a mutex, in the current implementation this issue is resolved throwing an exception with description template: "Mutex is locked by ${state.owner} but expected $owner"

However this use case can be nicely covered providing a complete toString() implementation

[elizarov]

Merged

[elizarov]

Released in version 0.18