Messages in this thread | | | Date | Sat, 17 Apr 2021 14:01:48 +0100 | From | Wedson Almeida Filho <> | Subject | Re: [PATCH 00/13] [RFC] Rust support |
| |
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
| |