lkml.org 
[lkml]   [2021]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2021-04-17 15:03    [W:0.187 / U:1.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site