ReadWriteLockWithUpgrade does not permit > 1 concurrent upgr

[bdueck]

Ben, Bela;

Wondering if you can explain why ReadWriteLockWithUpgrade.upgradeLockAttempt() does not allow more than 1 concurrent reader to upgrade their lock?

Although there are inherent inefficiencies if you have many readers competing for a lock upgrade, I can't see an inherent problem with the scenario.

In my case, I do have situations where multiple threads are trying to add different children to the same node on a cache with REPEATABLE_READ as the isolation level.

Any thoughts on this?

Brian.

[belaban]

Yes, this is on the todo list. There is a JIRA issue *and* a testcase (which fails). I want to use the util.concurrent WriterPreferredReaderWriteLock (or whatever it is called), to do this, but it's broken. Take a look at the unit test, it shows who (IMO) is broken with it. We should contact the util.concurrent folks at some time and get a clarification.

[belaban]

This case only happens when multiple threads hold locks on the *same* FQN, and everybody tries to upgrade to a write lock at the same time

[bdueck]

The problem with this issue is there is no real way for the application to preven the situation from occurring.

If you have concurrent access to a TreeCache, and it happens that a couple of threads all try to write to the same Fqn (a popular item :-) then whammo.

Although using the concurrent class would be the right way to solve this, could you elaborate on what the problem is with the current ReadWriteLockWithUpgrade that does not support > 1 upgraders?

I couldn't see how things would break so tried modifying the code to see what would happen if that check was removed - all tests passed and it solved the problem we found in our app.

Pending a change in concurrent utils, any problems with just removing this check? Also, can you see a fix to the concurrent problem, if so, what is it?

Brian.

[belaban]

Yes, we can fix this (it is a JIRA issue). However, there is a simple workaround:
- don't do a read first, do a write first, so you don't need to upgrade
The nature of the bug is described in ReentrantWriterPreferenceReadWriteLockTest.test2ReadersAnd1Writer()