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 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 : > > > 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 > > 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 : > > > > > > > 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 : > 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 > 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 : > > > > > 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 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 : > > > 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 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 : > >> 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
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 : > 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