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:4.509 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site