On Sat, Apr 17, 2021 at 12:41:23PM +0000, David Laight wrote:
> Or the cases where the locks are released in the 'wrong' order.
> Typically for:
> lock(table)
> item = lookup(table, key)
> lock(item)
> unlock(table)
> ...
> unlock(item)
This is expressible in Rust with something like:
table = table_mutex.lock()
item = table.lookup(key).lock()
drop(table)
...
// item will be unlocked when it goes out of scope or on drop(item)
The added bonus here from Rust is that table is not accessible after
drop(table), so a developer cannot accidentally access fields after unlocking
it.
>
> (In the kernel the table lock might be RCU.)
>
> Or, with similar data:
> write_lock(table);
> foreach(item, table)
> lock(item)
> unlock(item)
> /* No items can be locked until we release the write_lock.
> ...
> unlock(table)
I think I'm missing something here. Would you help me understand what part is
out of the ordinary in the code above? It would be expressible in Rust with
something like:
table = table_mutex.write();
for (item_mutex in table)
item = item_mutex.lock
// item is unlocked at the end of the loop iteration (out of scope)
// table gets unlocked when it goes out of scope
Cheers,
-Wedson
