I believe this could be a useful addition to Ignite. RWU-locks are not widely-spread in Java. But for example in .NET this is a base concurrency primitive. Of course users can handle "update" situations differently, e.g. "release read lock, then acquire write lock, then re-check condition, ...". But this is exactly where "update" semantics could free user from this burden. I think we will see some demand for this feature at least from .NET community.
On the other hand, I fully agree with Yakov that "update" is a kind of corner case. Standard "read lock" and "write lock" are much more common. We should implement distributed RWlock first. For RWULock we can at least create a JIRA ticket for now. If someone from community would like to implement it - then why not? Vladimir. On Tue, Jul 19, 2016 at 1:56 PM, Yakov Zhdanov <yzhda...@apache.org> wrote: > Hi Vlad! > > Thanks for bringing this up. > > I looked through concurrency-interest discussion, and I don't think we > should do this in Ignite. At least now. I am not sure if this will give any > advantage since only one thread can acquire UPDATE lock at the same time. > Btw, was there any benchmark published comparing UpdateLock vs RWLock > implementations? > > I think that in many cases read then update scenarios can be handled with > some kind of volatile or atomic read and then acquiring the ordinary lock > or by CAS operation. For the rest of cases we already have RWLock. > > And one more point - nobody asked for it. So, I ask - Does anyone need it > in Ignite? > > Thanks! > > --Yakov > > 2016-07-18 22:55 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>: > > > Hi everyone, > > > > cross-posting from JIRA: > > I recently came across this post: > > http://codereview.stackexchange.com/a/31231 > > > > Do you think ReadWriteUpdateLock is something we can put to good use here > > in Ignite? > > > > This kind of lock should be more efficient for read-before-write > patterns. > > > > Best regards, > > Vladisav > > >
