You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladisav Jelisavcic <vl...@gmail.com> on 2016/07/18 19:55:02 UTC
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
Re: ReadWriteUpdateLock
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <yz...@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 <vo...@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 <yz...@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 <vl...@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
Posted by Yakov Zhdanov <yz...@apache.org>.
Vova, we discuss this without having any numbers. Any real-life use case?
--Yakov
2016-07-20 9:48 GMT+03:00 Vladimir Ozerov <vo...@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 <yz...@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 <vl...@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
Posted by Vladimir Ozerov <vo...@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 <yz...@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 <vl...@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
Posted by Dmitriy Setrakyan <ds...@gridgain.com>.
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 <yz...@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 <vl...@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
Posted by Yakov Zhdanov <yz...@apache.org>.
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 <vl...@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
>