Improvement: add support for read/write locks

[LukeButters]

Hi
This project is rather nice, it seems to solve the releasing of unused locks rather well :). My problem however needs read/write locks. What are your thoughts in supporting read/write locks. The interface at the top would have methods:

void executeLockedExclusive(Object key, LockCallback callback);
void executeLockedShared(Object key, LockCallback callback);

Looking at your code it doesn't seem like it would be to complicated to add. I am happy to write the changes however I want to know if these features are something you want in the project.

-Luke

p.s. I raised this as a issue as I wasn't sure of a better way to discuss this with @mojgh and @Avinash-Bhat

[Avinash-Bhat]

@LukeButtersFunnelback I think having to create a read (shared or not) lock is not something should be done if possible.

The reason behind this is that the underlying resource can provide read synchronization by providing immutable data.

IMO given that the library stands for simplifying the use of Map<String, Lock> , this will be an unnecessary bloat.

Anyways, the final call is with @mojgh :-)

PS: I have not done any considerable contribution to the code. I have just helped to move the documentation from google-code.

[LukeButters]

Annoyingly the underlying resource can not provide immutable data 😞, hence the need for read/write locks.
I doubt that the library would increase in size by much. Further we could keep the existing interface and add a new interface for read/write, so wont break existing code 😄. By keeping the existing interface the library continues to simplify Map<String, Lock>

[Avinash-Bhat]

@LukeButtersFunnelback you can transform the mutable data into an immutable data while retrieving it.

If this is not possible (say, the resource is memory/cpu intensive) to do this, then there is nothing you can do not to make the required changes. In the worst-case scenario -- that it gets rejected, you will just have to maintain that branch. At anytime others are also asking for the same feature, @mojgh can merge it.

HTH

[mojgh]

I can imagine some scenarios where mutable data is necessary in conjunction with key locks.

I agree with Avinash-Bhats concern, to keep the library simple. Usage and if possible implementation and test should be as simple as possible. I think, we can find a solution that will meet these expectations.

In my opinion the simplest solution would be to replace ReentrantLock by ReentrantReadWriteLock and expand the interface accordingly.
What I do not like about this solution is that ReentrantLock for an exclusive lock is more efficient than ReentrantReadWriteLock and users of the existing solution
therefore would have to accept inferior efficiency.

I tend therefore to a solution with different implementations of StripedKeyLockManager without code duplication.
I will provide a poc branch in the near future.

@LukeButtersFunnelback: Can you describe your use case in an abstract way?

[LukeButters]

I had a go at implementing this, you can see the changes LukeButters@31119ff
importantly the complicated code to do with counting the number of uses of a lock has been moved to a separate class which is re-used by both implementations.
Note that doco is missing but seeing as it is mostly your code moved around you probably wont have a issue reading it ;)
Looking forward to comments @Avinash-Bhat and @mojgh