1 tháng học Rust - Đột biến dữ liệu và vay mượn quyền sở hữu

1 tháng học Rust - Đột biến dữ liệu và vay mượn quyền sở hữu

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm
  • Không biết blog được dẫn nguồn từ trang cà phê nào hay sao mà vài ba hôm trở lại đây thấy nhiều người tìm kiếm cà phê thế không biết 🤔.

    Tìm cả cách pha với tìm cả loại hạt, khổ nỗi họ tìm lại không ra bài viết nào vì mình chưa có viết đến mấy trường hợp đó. Phải chăng là ý trời 😀🙏

    » Xem thêm

Vấn đề

Ở bài viết trước chúng ta biết về khái niệm quyền sở hữu trong Rust. Nhờ có nó, Rust biết khi nào một biến là không dùng nữa và giải phóng giá trị khỏi bộ nhớ. Bằng cách sử dụng & trước tên biến, chúng ta khai báo với Rust rằng chỉ “mượn” tạm giá trị mà không chuyển quyền sở hữu nên biến được mượn vẫn tồn tại sau khi mượn, chỉ có điều nó mất đi một số quyền.

Bài viết ngày hôm nay sẽ đi sâu vào cách Rust hoạt động với hành vi mượn dữ liệu. Làm thế nào để nó ngăn chặn được hành vi “không chuẩn mực” với dữ liệu được mượn và bị mượn trong thời gian biên dịch chứ không phải là thời gian chạy (runtime).

Rust tránh việc mượn và đột biến dữ liệu đồng thời

Đầu tiên hãy xem qua cách mà Rust xử lý bộ nhớ trong chương trình này.

let mut v: Vec<i32> = vec![1, 2, 3];
v.push(4);

Rust tránh việc mượn và đột biến dữ liệu đồng thời

Tại L2, hành động thêm một phần tử vào một danh sách đã gây nên đột biến, nhưng thay vì thêm 4 vào ô nhớ tiếp theo thì Rust đã sao chép toàn bộ dữ liệu sang một vùng nhớ khác, điều đó khiến cho dữ liệu tại heap của v tại L1 đã bị giải phóng, v lúc này trỏ đến một ô nhớ khác.

Nếu như vậy thì điều gì sẽ xảy ra với chương trình dưới đây.

let mut v: Vec<i32> = vec![1, 2, 3];
let num: &i32 = &v[2];
v.push(4);
println!("Third element is {}", *num);

Chúng ta thấy num đang mượn giá trị tại vị trí thứ 2 của v thông qua cách gọi &v[2]. Nhưng sau hành động push, giá trị heap của v ban đầu đã bị hủy bỏ, vậy thì num lúc này trỏ đến đâu? Bạn nghĩ đúng rồi đấy, chương trình trên báo lỗi.

Rust tránh việc mượn và đột biến dữ liệu đồng thời - 2

Do đó, Rust phát biểu nguyên tắc an toàn của con trỏ: Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc.

Vì sinh ra cơ chế vay mượn, cho nên Rust cần tạo nên các quy tắc để đảm bảo "Nguyên tắc an toàn của con trỏ", đó chính là công cụ kiểm tra vay mượn (borrow checker).

Borrow checker

Ý tưởng cốt lõi Rust sinh ra loại 3 quyền sở hữu dữ liệu của một biến.

  • Read (R): Dữ liệu có thể được sao chép sang vị trí khác.
  • Write (W): Dữ liệu có thể được thay đổi.
  • Own (O): Dữ liệu có thể được di chuyển hoặc xóa.

Các quyền này chỉ tồn tại tại thời điểm biên dịch, tức là trình biên dịch "tự biên tự diễn" ra các quyền này để kiểm tra trương trình của bạn có hợp lệ hay không trước khi build thành binary.

Mặc định một biến có các quyền R, O trên dữ liệu của nó. Nếu một biến khai báo với mut, nó sẽ có thêm quyền W.

Hãy xem xét cách Rust kiểm tra quyền dữ liệu của biến trong chương trình sau.

Rust kiểm tra quyền

Đầu tiên, v được khai báo với mut nên nó có 3 quyền R, O, W. Sau đó num mượn giá trị của v, lúc này v bị mất 2 quyền W, O, bù lại num có quyền R, O trên dữ liệu mà nó mới mượn được. *num là biến đọc giá trị tại nơi vay mượn, nó chỉ có quyền R.

Ngay sau lệnh println!, num được giải phóng do đó v được khôi phục lại tất cả các quyền còn num*num mất hết quyền trên dữ liệu mà nó mượn.

Sau lệnh push, v không còn được dùng nữa cho nên nó cũng mất hết quyền trên dữ liệu của nó.

Rust gọi tất cả thứ nằm bên trái của phép gán (=) là paths. Từ đó, quyền sở hữu dữ liệu được xác định trên paths chứ không đơn thuần là trên các biến nữa. paths bao gồm:

  • Các biến, như a.
  • *a.
  • Truy cập vào phần tử trong mảng: a[0].
  • a.0 của Tuble hoặc a.field của Structs.
  • Và một số truy cập phức tạp khác: *((*a)[0].1) !?

Vậy thì một biến mượn dữ liệu của biến khác, nó có thay đổi được dữ liệu đó không? Hãy nhớ lại khái niệm: “Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc”, tức là chỉ 1 trong 2 được phép xảy ra cùng một lúc.

let mut v: Vec<i32> = vec![1, 2, 3];
let num: &mut i32 = &mut v[2];
*num += 1;
println!("Third element is {}", *num);
println!("Vector is now {:?}", v);

Rust kiểm tra quyền - 2

Thay vì &v[2], giờ đây chúng ta khai báo &mut v[2] để thông báo rằng num có quyền O với dữ liệu nó mượn. Biến *num đọc thẳng dữ liệu trong heap và tăng nó lên 1. Đến cuối cùng, v cũng bị thay đổi theo num.

So với ví dụ ban đầu, v bị mất hoàn toàn tất cả quyền khi num mượn một dữ liệu có quyền O. Điều này đảm bảo an toàn dữ liệu và tuân thủ nguyên tắc “Dữ liệu không bao giờ được đặt bí danh (vay mượn) và thay đổi cùng một lúc”.

Dữ liệu phải tồn tại lâu hơn các tham chiếu của nó

Hãy bắt đầu với một ví dụ:

let s = String::from("Hello world");
let s_ref = &s;
drop(s);
println!("{}", s_ref);

Đoạn mã trên đang cố gắng xóa s trong khi s_ref thì đang mượn giá trị của s. Nhớ lại kiến thức ở trên, s lúc này tạm thời bị mất quyền O cho nên drop không làm gì được vì nó yêu cầu phải có quyền O mới được phép. Chính vì thế chương trình trên báo lỗi.

Chúng ta, cũng như Rust có thể nhận biết được thời gian tồn tại của s bằng mắt thường một cách nhanh chóng, tuy nhiên, chương trình không phải lúc nào cũng đơn giản, buộc Rust phải có cách nhận biết được thời gian tồn tại đủ lâu của một biến trong chương trình để tránh trường hợp như trên.

Hãy xem xét ví một hàm này.

fn first_or(strings: &Vec<String>, default: &String) -> &String {
    if strings.len() > 0 {
        &strings[0]
    } else {
        default
    }
}

Hàm có thể trả về String đầu tiên của tham số strings hoặc cũng có thể trả về tham số default. Sẽ ra sao nếu như chúng ta gọi hàm như thế này.

fn main() {
    let strings = vec![];
    let default = String::from("default");
    let s = first_or(&strings, &default);
    drop(default);
    println!("{}", s);
}

strings là rỗng, nên s bằng tham chiếu của default, tuy nhiên một lệnh drop(default) được gọi trước khi in ra s. Do đó chương trình này là không an toàn và nó bị lỗi.

Một ví dụ khác về chương trình không an toàn.

fn return_a_string() -> &String {
    let s = String::from("Hello world");
    let s_ref = &s;
    s_ref
}

s_ref đang cố gắng mượn giá trị của s, tuy nhiên kết thúc hàm thì s sẽ được giải phóng, việc trả về s_ref lúc này là vô nghĩa vì thế chương trình trên báo lỗi.

Tổng kết

Vậy là kết thúc bài viết nói về quyền sở hữu và cách Rust kiểm tra quyền vay mượn dữ liệu. Theo cảm nhận của tôi thì đây là phần khái niệm khó hiểu nhất của Rust, nhưng nó lại là khái niệm quan trọng nếu muốn viết và gỡ lỗi chương trình. Bạn đọc có thể tiếp tục đọc thêm bài viết Fixing Ownership Errors để biết cách sửa một số lỗi thường gặp với quyền sở hữu.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (2)

Nội dung bình luận...
Avatar
Ẩn danh1 năm trước
"lúc này v bị mất 2 quyền W, O, bù lại num có quyền R, O trên dữ liệu mà nó mới mượn được". References không chiếm quyền sở hữu, nó chỉ mượn (borrowing), giống như biến, ref cũng có 2 kiểu mượn là immutable vs mutable nhưng có phụ thuộc vào owner, nếu owner khai bao với mutable thì ref với được mutable
Trả lời
Avatar
Ẩn danh1 năm trước
"Tại L2, hành động thêm một phần tử vào một danh sách đã gây nên đột biến, nhưng thay vì thêm 4 vào ô nhớ tiếp theo thì Rust đã sao chép toàn bộ dữ liệu sang một vùng nhớ khác". chỗ này không phải lúc nào cũng cũng được cấp phát mới vùng nhớ, nó phục thuộc vào cái cap của Vec, khi len > cap thì Vec mới được cấp phát với cap mới là x2, vì vậy để tối ưu chương trình nếu biết len của Vec cần sử dụng thì thường người ta sẽ khởi tạo nó với cap được xác định trước để tránh bị cấp phái lại nhiều lần
Trả lời
Bấm hoặc cuộn mạnh để sang bài mới