Greedy read lock for RwLock about spin-rs HOT 4 OPEN

My specific use case is that I need to be able to lock in the current state when some event happens (without blocking that thread)

I’m interested in potentially implementing this, but I don’t think I’m understanding the use case completely. Looking at the gist, the read implementation doesn’t lock in the current state of the protected data until the Deref finishes spinning (since there may still be a writer mutating the data). Is the idea here just to signal early that future writers should wait so a reader is less likely to wait?

from spin-rs.

You are essentially correct, the most important part of this is to signal that future writers need to wait, however in my system this approach serves a few purposes.

1. Relatively efficient reading:: When I take a readlock I don't tend to use that state right away, so there is generally time for the active writer to finish up, and my readers won't actually spin when they go to use the data.
2. Locking in the state at any time:: This includes if I am still currently updating it and goes hand-in-hand with my first point.
3. Not blocking to get the value until I actually need to use it:: This also goes hand-in-hand with my first point.

To put this into a little context, I have an actor system where each actor exposes some "state". There are events in the system which require me to lock in various actor's states as quickly as possible, and pass those locks onto other actors to be consumed (in their own threads) whenever they can get around to it.

Here is an updated gist with the code I am currently using in production: https://gist.github.com/Visic/3c951421b1e15c809f207dfa34bff30e

Edit: This approach has been working wonderfully for me for almost a year now. I am happy to answer questions, but I might need to be a little vague as to the actual system I am working on.

from spin-rs.

Awesome, thanks for the explanation! I guess I'm still a little confused on this part:

Locking in the state at any time:: This includes if I am still currently updating it and goes hand-in-hand with my first point.

Based on the implementation you have in the gist and your description, I don't fully understand what you mean by "locking in the state", since a current writer isn't prevented from writing after read returns but before deref returns. It's might just be that a different API is needed for this, but it seems like this breaks the semantics of read.

from spin-rs.

I think I understand your confusion, in the new gist you'll see I removed the write guard in favor of a "try_update" method, meaning that a write lock can only be used for a single update operation. This equates to "locking in the state" since the only write that can be performed after a read lock is requested, is one that is already in progress.

I'm sure the same could be done if I gave out write locks still by only using them for a single update before dropping the lock, so with the original interface, that point is really more about how I was using it rather than the actual guarentees, and it would be more accurate to just say that a new writer couldn't be given out once a reader was requested.

from spin-rs.