Administrivia

• “Lab 3: FAT32 Filesystem” is due on Mar 2!

Administrivia

• Proposal day:
  • Two days to accommodate the larger number of teams/students
  • Slides DUE on Feb 24! (2-day earlier than the original plan)
  • Feedback from peers (individually to each team)
    1. Overall rating (0-5): I will give you this if you complete as promised
    2. Coolness (0-5): how impressive is it as a final project?
    3. Difficulty (0-5): indicating potential risks in my perspective
    4. Any comment: e.g., is it super cool to demo A ..
  • Check our web site for ideas

Administrivia

• In the proposal (elevator pitch, early feedback), include:
  1. Goal, Motivation, Problem or Statement
  2. Demo plan
  3. Timeline (1pg, just append at the end)
• Don’t overcommit: it would disappoint peers in the demo day
• Okay to regroup or even change the idea after!
• No evaluation for proposal itself
• Final evaluation: average of overall ratings from peers

Q&A

It seems the entirety of the Rust standard library is built on top of unsafe code. Granted I understand why this is the case, I don’t understand why we can call Rust “safe.” No matter how structurally sound you build a building, if you build its foundation on unstable ground the building cannot truly be safe.

Agenda

• Remind: Rust’s safety rule
• Interior mutability patterns
• New abstractions: Cell, RefCell, UnsafeCell

(Again) Safety rule

• Aliasing: many shared references
• Mutability: unique mutable reference
• Safety rule: aliasing xor mutability

Example

// in C++
std::string s = "Hello";
const char *c = s.c_str();

s.append(" World!");

std::cout << c;

// in Rust
let mut s = String::from("Hello");
let c = s.as_str();
    
s.push_str(" World!");

dbg!(c);

More examples

• Error-prone cases that Rust would statically prevent
  • string_view
  • iterator
  • etc.

Mutability in Rust

• Inherited mutability (aka, external mutability)

struct S {
  e1: u32,
  e2: u32,
}

let mut s = S { e1: 1, e2: 2 };
//  ---> determins mutability of all elements of struct S

change_me(&mut s);

Rc: Reference counted smart pointer

• Q. how does Rc work and what’s for?
• Q. how is clone() implemented?

let r1 = Rc::new(1);
let r2 = Rc::clone(&r1);

dbg!(r1);
dbg!(r2);

Rc: Reference counted smart pointer

// simplified
pub struct Rc<T> {
  ptr: NonNull<RcBox<T>>
  phantom: PhantomData<T>,
}

struct RcBox<T> {
  strong: Cell<usize>,
  weak: Cell<usize>,
  value: T,
}

// note: &self not &mut self
fn clone(&self) -> Rc<T> {
  self.strong.set(self.strong + 1); // Q. guess?
  Rc { ptr: self.ptr }
}

Introducing Cell

• Allow modification w/o mutable references

pub fn get(&self) -> T;
pub fn set(&self, val: T);
pub fn replace(&self, val: T) -> T;

// example:
struct RcBox<T> {
  strong: Cell<usize>, // mutable!
  weak: Cell<usize>,   // mutable!
  value: T,
}

Example: Cell interfaces

• No “mutable” annotated but the modification is indeed made!
• Q. What could go wrong in this code?
• Q. Is the safety rule violated?

let c = Cell::new(10);
let v1 = c.get();

c.set(v1 + 10);

let v2 = c.get(); // v1 != v2
dbg!(v2);         //=> 20

Wait, Q&A

• Q. Wait, why did we want to avoid multiple mutable references at the first place?
• Q. How to compare Cell to C’s pointer?

Doesn’t Cell defeat the entire purpose of Rust (to provide simpler memory safety)? In addition, if not, then why isn’t Cell used for all mutable pointers when multiple mutable pointers attempt to access the same memory location?

Wait, Q&A

// in Rust
let mut s = String::from("Hello");
let c = s.as_str(); // Q?
    
s.push_str(" World!"); // Q?

dbg!(c); // Q?

Thinking of Cell

• Perhaps, safe as far as the compiler doesn’t optimize Cell?
  • Given &T, a compiler knows there is no mutably aliased references
  • Introducing UnsafeCell<T>!
• Permitting mutability in a controlled manner
  • Copy-able types can be stored/loaded to/from Cell as a whole

Note, not thread safe to access them concurrently, more on this topic later

Example implementation

impl<T> Cell<T> {
  pub fn set(&self, val: T) {
    let old = self.replace(val);
    drop(old);
  }

  pub fn replace(&self, val: T) -> T {
    // Q. Safety is well-justified?
    mem::replace(unsafe { &mut *self.value.get() }, val)
  }
}

Thinking of “Interior mutability”

• The safety rule is too restrictive, excluding truly safe code!
• Example: what if there is no reference at the first place?
  • Clear copy in and out
  • Not shareable across threads
  • Then, is it safe to modify when other outstanding immutable references exit?

Core type: UnsafeCell

#[repr(transparent)] // Q?
pub struct Cell<T: ?Sized> {
    value: UnsafeCell<T>,
}

#[lang = "unsafe_cell"]
#[repr(transparent)]
pub struct UnsafeCell<T: ?Sized> {
    value: T,
}

pub const fn get(&self) -> *mut T {
  // We can just cast the pointer from `UnsafeCell<T>` to `T` because of
  // #[repr(transparent)]
  self as *const UnsafeCell<T> as *const T as *mut T
}

RefCell: dynamically checked borrowing rules

• The safety rule (aliasing xor mutability) is dynamically enforced

let c = RefCell::new(10);
let s1 = c.borrow();
let s2 = c.borrow();

let mut m1 = c.borrow_mut(); // Q. what should happen?

Thinking of “Interior mutability”

• Q. Is it safe to modify in that way?
• Example: what if we can guarantee there is only one mutable reference at runtime?
  • Clear tracking of references generation: borrow()/borrow_mut()
  • Not shareable across threads
  • Any violation of this rule → panic!

Bonus, what if we wait instead of panicing?

1. What if there exists only one outstanding sharable/immutable reference at runtime?
2. Is the safety rule correctly enforced at runtime?
3. Thus, is it safe to let immutable variables modifiable?

Summary

• Safe abstractions that Rust can’t statically assure:
  • Rc allowing multiple ownership (via reference counting)
  • Cell concerning on limited uses of inherited mutability (by restricting references)
  • RefCell bypassing the borrow checks at compilation time (via check at runtime)
• Core abstraction: UnsafeCell restricts Rustc’s reasoning on aliasing/mutability

Note. limited our discussion to a single thread context

Compositing Rc and Cell

• Multiple owners, writing to immutable variable
• Q. falling back to C? should we consider unsafe?

    let r = Rc::new(Cell::new(10));

    let c1 = Rc::clone(&r);
    let c2 = Rc::clone(&r);

    c1.set(20);
    c2.set(30);

    dbg!(c1); //=> Q?
    dbg!(c2); //=> Q?

“Interior Mutability” Patterns

• Never handing out references: Cell (Atomic)
• Ensuring at runtime a mutable reference is unique: RefCell (Mutex, RWLock)
• Mutability only during initialization: OnceCell, lazy_static

Ref. Interior mutability patterns

References

• Interior mutability patterns
• Reddit Q&A
• StackOverflow Q&A
• Rust: A unique perspective