Your benchmarks just show a few nested "read_txn"es from what i saw but that's not lock coupling.
Lock coupling would be taking the lock on the root element of a tree or head element of a list, then taking the lock on the second element and then releasing the first one again so that you actually only hold at most 2 locks (whether it's optimistic ones or not doesn't really matter) at each point in time. With the lambda based nesting this obviously wouldn't be possible. With the guard variant it would also probably not be possible because you would have to move the "current" value to a "parent" variable or whatever while still holding the lock.
In my opinion the only way something like this works is by having a kind of "owning lock guard" like parking_lot has when you activate the arc_lock feature which would however probably destroy a lot of your performance if you actually used it element wise for something like an in-memory linked list (probably more acceptable for a B-Tree) because you would then again have to do an atomic write to a reference counter when the atomic write is something you wanted to avoid in the first place. The other way would probably be to use a GC like crossbeam_epoch which is probably the better option. Without that it's probably rather hard to get a safe and also performant implementation of an optimistic lock that can do this in Rust.
If there actually is a way to implement proper lock coupling with your api, i would be happy if you could explain it to me.
Your benchmarks just show a few nested "read_txn"es from what i saw but that's not lock coupling.
Lock coupling would be taking the lock on the root element of a tree or head element of a list, then taking the lock on the second element and then releasing the first one again so that you actually only hold at most 2 locks (whether it's optimistic ones or not doesn't really matter) at each point in time. With the lambda based nesting this obviously wouldn't be possible. With the guard variant it would also probably not be possible because you would have to move the "current" value to a "parent" variable or whatever while still holding the lock.
In my opinion the only way something like this works is by having a kind of "owning lock guard" like parking_lot has when you activate the arc_lock feature which would however probably destroy a lot of your performance if you actually used it element wise for something like an in-memory linked list (probably more acceptable for a B-Tree) because you would then again have to do an atomic write to a reference counter when the atomic write is something you wanted to avoid in the first place. The other way would probably be to use a GC like crossbeam_epoch which is probably the better option. Without that it's probably rather hard to get a safe and also performant implementation of an optimistic lock that can do this in Rust.
If there actually is a way to implement proper lock coupling with your api, i would be happy if you could explain it to me.