ReadWriteUpdateLock

[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

[yzhdanov]

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 <[hidden email]>:

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

[Dmitriy Setrakyan]

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 <[hidden email]> 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 <[hidden email]>:
>
>> 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
>>

[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 <[hidden email]> 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 <[hidden email]>:
>
> > 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
> >
>

[yzhdanov]

Vova, we discuss this without having any numbers. Any real-life use case?

--Yakov

2016-07-20 9:48 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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
> > > >
> > >
> >
>