網(wǎng)站首頁 編程語言 正文
Rust內存序
Memory Ordering規(guī)定了多線程環(huán)境下對共享內存進行操作時的可見性和順序性,防止了不正確的重排序(Reordering)。
重排序和優(yōu)化
重排序是指編譯器或CPU在不改變程序語義的前提下,改變指令的執(zhí)行順序。在單線程環(huán)境下,重排序可能會帶來性能提升,但在多線程環(huán)境下,重排序可能會破壞程序的正確性,導致數(shù)據(jù)競爭、死鎖等問題。
Rust提供了多種內存序,包括Acquire、Release、AcqRel、SeqCst等。這些內存序規(guī)定了在不同情況下,線程之間進行共享內存的讀寫時應該保持的順序和可見性。
除了內存序之外,編譯器還可以進行優(yōu)化,例如常數(shù)折疊、函數(shù)內聯(lián)等。這些優(yōu)化可能會導致指令重排,從而影響多線程程序的正確性。為了避免這種情況,Rust提供了關鍵字volatile
和compiler_fence
來禁止編譯器進行優(yōu)化,保證程序的正確性。
總的來說,Rust的內存序機制和優(yōu)化控制機制可以幫助程序員在多線程環(huán)境下編寫高效且正確的程序。 下面是一個簡單的 Rust 代碼示例,它演示了 Rust 中的代碼重新排序和優(yōu)化如何影響程序行為:
use std::sync::{Arc, Mutex}; use std::thread; fn main() { let shared_counter = Arc::new(Mutex::new(0)); let mut threads = vec![]; for i in 0..10 { let counter = shared_counter.clone(); let t = thread::spawn(move || { let mut num = counter.lock().unwrap(); *num += i; }); threads.push(t); } for t in threads { t.join().unwrap(); } let final_counter = shared_counter.lock().unwrap(); println!("Final value: {}", *final_counter); }
在這個示例中,我們創(chuàng)建了一個共享計數(shù)器 shared_counter
,它被多個線程并發(fā)地訪問和修改。為了保證線程安全,我們使用了一個 Mutex
來對計數(shù)器進行互斥訪問。
在主線程中,我們創(chuàng)建了 10 個子線程,并讓它們分別增加計數(shù)器的值。然后我們等待所有線程都執(zhí)行完畢后,打印出最終的計數(shù)器值。
在這個示例中,由于 Rust 的內存序保證,所有對共享變量的訪問和修改都按照程序中的順序進行。也就是說,每個線程增加計數(shù)器的值的操作不會重排到其他線程之前或之后的位置。
不過,如果我們在代碼中加入一些優(yōu)化指令,就可能會破壞這種順序。比如,下面這段代碼就使用了 fence
指令來保證所有線程對共享變量的修改都在主線程中得到了同步:
use std::sync::{Arc, Mutex}; use std::thread; fn main() { let shared_counter = Arc::new(Mutex::new(0)); let mut threads = vec![]; for i in 0..10 { let counter = shared_counter.clone(); let t = thread::spawn(move || { let mut num = counter.lock().unwrap(); *num += i; std::sync::atomic::fence(std::sync::atomic::Ordering::SeqCst); }); threads.push(t); } for t in threads { t.join().unwrap(); } let final_counter = shared_counter.lock().unwrap(); println!("Final value: {}", *final_counter); }
在這個示例中,我們在每個子線程結束時都加入了一個 fence
指令,來確保所有線程對共享變量的修改都在主線程中得到了同步。這樣一來,雖然所有線程對計數(shù)器的修改仍然是并發(fā)進行的,但它們對計數(shù)器的修改操作的順序可能會被重新排序,從而導致最終的計數(shù)器值與期望值不同。 但是,這可能是由于編譯器的優(yōu)化策略和硬件平臺的差異所導致的。在某些情況下,編譯器可能會選擇不進行代碼重排或重新優(yōu)化,因為這可能會影響程序的正確性。但是,在其他情況下,編譯器可能會根據(jù)其優(yōu)化策略和目標平臺的特性來對代碼進行重排和重新優(yōu)化,這可能會導致程序的行為發(fā)生變化。
happens-before
Rust內存模型中的“happens-before”原則指的是,如果一個操作A happens before 另一個操作B,那么A在時間上先于B執(zhí)行,而且A對內存的影響對于B是可見的。這個原則被用來解決多線程環(huán)境下的數(shù)據(jù)競爭問題,確保程序的執(zhí)行順序是有序的,避免出現(xiàn)未定義的行為。
具體來說,Rust內存模型中的happens-before原則包括以下幾個方面:
- 內存同步操作:Rust的內存同步操作(如acquire、release、acqrel、seq_cst)會創(chuàng)建一個happens-before的關系,保證該操作之前的所有內存訪問對該操作之后的內存訪問都是可見的。
- 鎖機制:Rust的鎖機制(如Mutex、RwLock)也會創(chuàng)建happens-before的關系,保證鎖內的操作是有序的,避免數(shù)據(jù)競爭問題。
- 線程的啟動和結束:Rust的線程啟動函數(shù)(如thread::spawn)會創(chuàng)建happens-before的關系,保證線程啟動之前的所有內存訪問對于該線程中的所有操作都是可見的。線程結束時也會創(chuàng)建happens-before的關系,保證該線程中的所有操作對于其他線程都是可見的。
- Atomics:Rust的原子類型(如AtomicBool、AtomicUsize)也會創(chuàng)建happens-before的關系,保證對于同一個原子變量的多次操作是有序的,避免數(shù)據(jù)競爭問題。
總之,Rust內存模型中的happens-before原則確保程序的執(zhí)行順序是有序的,避免出現(xiàn)未定義的行為,從而幫助開發(fā)者避免數(shù)據(jù)競爭問題。
Relexed Ordering
在 Rust 中,Relaxed Ordering 是一種較弱的內存順序,它允許線程在不同于程序中寫入順序的順序中讀取或寫入數(shù)據(jù),但不會導致未定義的行為。
Relaxed Ordering 主要應用于不需要同步的操作,比如單線程的計數(shù)器、讀取全局配置等場景。使用 Relaxed Ordering 可以避免不必要的內存屏障,提高程序的性能。
在 Rust 中,可以通過 std::sync::atomic::AtomicXXX
類型來使用 Relaxed Ordering。比如下面這個示例:
use std::sync::atomic::{AtomicUsize, Ordering}; fn main() { let counter = AtomicUsize::new(0); counter.fetch_add(1, Ordering::Relaxed); let value = counter.load(Ordering::Relaxed); println!("counter: {}", value); }
在這個示例中,我們使用 AtomicUsize
類型創(chuàng)建了一個計數(shù)器 counter
,然后使用 fetch_add
方法對計數(shù)器進行自增操作,并使用 load
方法讀取當前計數(shù)器的值。在 fetch_add
和 load
方法中,我們使用了 Ordering::Relaxed
參數(shù),表示這是一個 Relaxed Ordering 的操作,不需要執(zhí)行額外的內存屏障。
需要注意的是,使用 Relaxed Ordering 時需要保證程序中不存在數(shù)據(jù)競爭。如果存在數(shù)據(jù)競爭,就可能會導致內存重排和未定義的行為。因此,建議僅在確信不會出現(xiàn)數(shù)據(jù)競爭的情況下使用 Relaxed Ordering。
Release 和 Acquire Ordering
在 Rust 中,Release 和 Acquire Ordering 通常用于實現(xiàn)同步原語,例如 Mutex 和 Atomic 原子類型,以確保線程之間的正確同步。
Acquire Ordering 表示一個讀取操作所需的同步操作。在讀取操作之前,必須確保任何在之前的寫入操作都已經(jīng)完成,并且這些寫入操作對其他線程可見。在 Acquire Ordering 中,讀取操作前的任何寫入操作都不能被重排序到讀取操作之后。
Release Ordering 表示一個寫入操作所需的同步操作。在寫入操作之后,必須確保任何在之后的讀取操作都能夠看到這個寫入操作的結果,并且這個寫入操作對其他線程可見。在 Release Ordering 中,寫入操作后的任何讀取操作都不能被重排序到寫入操作之前。
下面是一個簡單的示例,說明了如何使用 Release 和 Acquire Ordering 來同步多個線程對共享狀態(tài)的訪問:
use std::sync::atomic::{AtomicUsize, Ordering}; use std::thread; static SHARED_STATE: AtomicUsize = AtomicUsize::new(0); fn main() { let mut threads = Vec::new(); for i in 0..5 { let thread = thread::spawn(move || { let mut local_state = i; // 等待其他線程初始化 thread::sleep_ms(10); // 將本地狀態(tài)更新到共享狀態(tài)中 SHARED_STATE.store(local_state, Ordering::Release); // 讀取共享狀態(tài)中的值 let shared_state = SHARED_STATE.load(Ordering::Acquire); println!("Thread {}: Shared state = {}", i, shared_state); }); threads.push(thread); } for thread in threads { thread.join().unwrap(); } }
在這個例子中,五個線程將本地狀態(tài)更新到共享狀態(tài)中,并讀取其他線程更新的共享狀態(tài)。為了確保正確的同步,我們使用 Release Ordering 來保證寫入操作的同步,Acquire Ordering 來保證讀取操作的同步。在每個線程中,我們使用 thread::sleep_ms(10)
使所有線程都能夠開始執(zhí)行,并等待其他線程完成初始化。在主線程中,我們使用 join
等待所有線程完成。運行此程序,輸出可能類似于以下內容:
Thread 0: Shared state = 3
Thread 1: Shared state = 0
Thread 2: Shared state = 2
Thread 3: Shared state = 1
Thread 4: Shared state = 4
這表明每個線程都能夠正確地讀取其他線程更新的共享狀態(tài),并且寫入操作在讀取操作之前完成。
SeqCst Ordering
SeqCst是Rust內存模型中的一種內存順序,它保證了所有的操作都按照順序執(zhí)行。SeqCst可以用于實現(xiàn)最嚴格的同步,因為它確保了所有線程都看到相同的執(zhí)行順序,因此被廣泛用于實現(xiàn)同步原語。 如果無法確認使用哪種排序的話,可以直接使用SeqCst
使用SeqCst內存順序時,讀操作和寫操作的執(zhí)行順序都是全局可見的,因此可以避免數(shù)據(jù)競爭和其他問題。但是SeqCst內存順序會導致一些性能問題,因為它要求所有線程都同步執(zhí)行,這可能會導致一些線程被阻塞。
以下是一個簡單的示例,展示了如何在Rust中使用SeqCst內存順序:
use std::sync::atomic::{AtomicBool, Ordering}; fn main() { let val = AtomicBool::new(false); val.store(true, Ordering::SeqCst); let result = val.load(Ordering::SeqCst); println!("Result: {}", result); }
在這個示例中,我們創(chuàng)建了一個AtomicBool
類型的變量val
,并將其初始值設置為false
。然后,我們使用store
方法將其值設置為true
,并使用load
方法讀取它的值。在這里,我們使用了SeqCst
內存順序,以確保所有線程都按順序執(zhí)行。在這個例子中,程序會輸出Result: true
,因為我們使用了SeqCst
內存順序,保證了所有線程都看到相同的執(zhí)行順序。
原文鏈接:https://juejin.cn/post/7204115174411845691
- 上一篇:沒有了
- 下一篇:沒有了
相關推薦
- 2022-09-21 ubuntu22通過docker安裝wechat啟動后無界面的問題及解決方法_docker
- 2022-07-29 Linux文件管理方法介紹_linux shell
- 2023-02-03 VSCode中ESLint插件修復以及配置教程_相關技巧
- 2022-12-09 C語言新手練習題之求第n個斐波那契數(shù)_C 語言
- 2022-05-31 詳解Docker?Compose配置文件參數(shù)_docker
- 2023-03-18 Android?UI動態(tài)設置帶有Stroke漸變色背景Drawable_Android
- 2023-11-15 Latex解決表格過寬問題,自適應調整寬度;自動調整適合的表格大小
- 2022-11-09 WPF使用WrapPanel實現(xiàn)虛擬化效果_C#教程
- 欄目分類
-
- 最近更新
-
- window11 系統(tǒng)安裝 yarn
- 超詳細win安裝深度學習環(huán)境2025年最新版(
- Linux 中運行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎操作-- 運算符,流程控制 Flo
- 1. Int 和Integer 的區(qū)別,Jav
- spring @retryable不生效的一種
- Spring Security之認證信息的處理
- Spring Security之認證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權
- redisson分布式鎖中waittime的設
- maven:解決release錯誤:Artif
- restTemplate使用總結
- Spring Security之安全異常處理
- MybatisPlus優(yōu)雅實現(xiàn)加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務發(fā)現(xiàn)-Nac
- Spring Security之基于HttpR
- Redis 底層數(shù)據(jù)結構-簡單動態(tài)字符串(SD
- arthas操作spring被代理目標對象命令
- Spring中的單例模式應用詳解
- 聊聊消息隊列,發(fā)送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠程分支