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 >
