Add RwLockReadGuard::upgrade method to obtain RwLockWriteGuard

[allevo]

Is your feature request related to a problem? Please describe.
I have a procedure that can be split into two parts:

• Calculate the changes: this takes time and requires only read permission
• Apply the changes: this is fast and requires write permission

Those operations rely on the same locked data. I cannot guarantee the calculated changes are valid before acquiring the write guard because the thread can be yielded in the middle.

let read_guard = my_rw_lock.read();
let delta = calculate_delta(&read_guard);
drop(read_guard);

my_async_fn().await; // possible yield

let write_guard = read_guard.upgrade().await;
apply_delta(&write_guard, delta);
drop(write_guard);

Describe the solution you'd like
I would like to have a way to upgrade the read guard to a write guard, so I can write something like:

let read_guard = my_rw_lock.read();
let delta = calculate_delta(&read_guard);
let write_guard = read_guard.upgrade().await;
apply_delta(&write_guard, delta);
drop(write_guard);

In this way, I'm sure the delta is valid.

Describe alternatives you've considered
I haven't found any solutions

Additional context

[sfackler]

That style of API will deadlock if there are there are ever 2 concurrent tasks trying to upgrade. A special "upgradable read" mode can avoid that: https://docs.rs/parking_lot/latest/parking_lot/type.RwLock.html#method.upgradable_read.

[Darksonn]

Tokio's rwlock is implemented using a semaphore. I don't think we can implement upgradable reads with a semaphore, and we're not going to completely change the implementation just for this.

[allevo]

Hi @sfackler. If you want we can discuss about the API in order to avoid deadlock (I wrote it without any special experience in tokio lib). I don't understand what do you want to say with that link. Can you elaborate more?

Thanks @Darksonn for your reply. I understood the complexity of this task and your reply highlight a possible blocker for this implementation. Do you any suggestion how I can implement it? (with tokio or other libraries).

[sfackler]

Can you elaborate more?

What happens if two threads currently hold a read lock, and both decide that they want to upgrade to a write lock?

[allevo]

What happens if two threads currently hold a read lock, and both decide that they want to upgrade to a write lock?

The upgrade should fail imho.

[Darksonn]

Making the upgrade fail would also require tracking new information, and I don't think we should make the RwLock type larger for this feature either.

[nevakrien]

I think you could implement this with a compare exchange.

Since the only time you are allowed to aquire the lock is when no one else is holding it that would mean that the number of readers is 1. You then want to do

Compare_exchange(cond,1,-1)

If this succeeds then you have unique access and of it fails the error can give back your read lock.

[nevakrien]

made a rough draft of how this can look like
#7284

[Darksonn]

Yes, it's possible to implement try_upgrade, but it doesn't really help with the use-case that this issue proposes to add the method for. In fact, I think it's pretty rare that try_upgrade is useful, because even if you only have one user it still has no mechanism to wait for readers to go away.

[nevakrien]

I see ur point, the waiting mechanism itself is not gonna be an easy change.
so this thing is likely too neich to implement although you could do it if it was needed.

maybe a seprate struct? maybe in another crate? that does this weird neich thing of letting u upgrade a lock.