Re: ReadWriteUpdateLock
I hardly can image where we can get concrete numbers of method usages. RWU lock is just a base .NET primitive. There are no plain RW lock there, only RWU. Users are just used to it. But again, my point is - let's implement standard RW lock first and then think about such extensions. On Wed, Jul 20, 2016 at 4:29 PM, Yakov Zhdanov <yzhda...@apache.org> wrote: > Vova, we discuss this without having any numbers. Any real-life use case? > > --Yakov > > 2016-07-20 9:48 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > 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 > > > > > > > > > >
Re: ReadWriteUpdateLock
Vova, we discuss this without having any numbers. Any real-life use case? --Yakov 2016-07-20 9:48 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > 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 > > > > > >
Re: ReadWriteUpdateLock
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 > > >
Re: ReadWriteUpdateLock
I think the basic RW lock is very much needed. As far as additional features, we should wait for community feedback in my view. Dmitriy > On 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 >>
ReadWriteUpdateLock
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
