^
Về Arc với Mutex thì nó liên quan đến code parallel/concurrent để tăng khả năng xử lý bác ợ. Về nguyên tắc cơ bản thì 2 cách chạy là:
- Parallel: 2 luồng độc lập cùng xử lý.
- Concurrent: 1 luồng chạy nhiều việc cùng lúc, nhưng nếu với việc phải đợi kết quả (query database hoặc query HTTP v.v.) thì chuyển sang việc khác.
Quay về Arc với Mutex của Rust thì nó lại liên quan đến một nguyên tắc khác về đọc/ghi dữ liệu, bất kể mình đang chạy concurrent hay parallel: trong 1 thời điểm, có thể có 1 hoặc nhiều luồng đọc song song, nhưng đọc xong thì chỉ có 1 luồng được ghi, và sau khi ghi xong thì mới cho phép đọc tiếp. Rust đưa ra các cấu trúc dữ liệu để đảm bảo việc này:
- Mutex để đảm bảo việc chỉ có 1 luồng đang đọc hoặc ghi dữ liệu xuống
- Tương tự, có RwLock để đảm bảo nhiều luồng đọc, nhưng vẫn 1 luồng ghi
Cơ mà Mutex thì lại không thể được chia sẻ giữa nhiều luồng khác nhau, từ đấy nó mới phải bị "gói" ở trong Arc. Arc đơn giản là 1 cái "hộp" được chia sẻ giữa nhiều luồng khác nhau, nhưng có 1 bộ đếm đi kèm với nguyên tắc là 1 nếu được dùng đến thì bộ đếm tăng lên; nếu không được dùng nữa thì bộ đếm giảm đi và đến cuối cùng, số đếm đó về 0. Khi số đếm về 0, cái được đựng bên trong "'hộp" cũng được giải phóng.
---
Cái Talent Plan kia là của công ty Pingcap, chuyên về database. Họ có 1 cái khóa học về Rust bằng cách cho mình tự tay viết 1 cái KV database (đơn giản hơn Redis), từ đơn giản đến phức tạp. Lúc đầu thì bác chỉ chạy cái KV database trong bộ nhớ, xong rồi expose nó dưới dạng single-threaded TCP server, rồi thêm xử lý concurrency thì dùng đến Arc Mutex. Mình được hướng dẫn luôn về error handling các thứ em thấy cũng hay và hạp lý
github.com
