使用Rust开发操作系统(print!和println!宏实现)
print!和println!宏实现
在上一章中我们实现了基本的打印功能,现在的打印功能使用起来不是很方便,因此我们对之前编写打印功能进行优化
自旋锁
原子操作
为了更好理解自旋锁,我们需要了解一下原子操作,原子操作指在执行过程中不会被任何其它任务或事件中断,一个任务要么做要么不做,不能在做的过程中被打断,这个特性需要硬件支持在x86平台上,CPU提供了在指令执行期间对总线加锁的手段
Rust中的原子操作
在Rust中我们可以使用std::sync::atomic
包来使用原子操作,在#![no_std]
环境中我们可以使用core::sync::atomic
使用
atomic包提供了AtomicBool,AtomicIsize,AtomicUsize,AtomicI8,AtomicU16等类型的原子操作
每个方法都会使用Ordering
枚举表明内存屏障的强度,Rust的原子顺序LLVM原子顺序一致,原子类型可以存储在静态变量中,可以使用常量初始化程序(如AtomicBool :: new)进行初始化
原子访问可以告诉硬件和编译器,我们的程序是多线程的。每一个原子访问都关联一种 “排序方式”,以确定它和其他访问之间的关系。归根结底,就是告诉编译器和硬件什么是它们不能做的。对于编译器,主要指的是命令的重排。而对于硬件,指的是写操作的结果如何同步到其他的线程
— 《Rust高级编程》
Ordering
内存顺序(Memory orderings)指定原子操作同步内存的方式,以下是常用的几种状态
- Relaxed
- Release(获取)
- Acquire(释放)
- AcqRel
- SeqCst(顺序一致性)
以下内容摘自《Rust高级编程》,感觉解释比我好,PS:才不是因为懒 (笑)
顺序一致性
顺序一致性是所有排序方式中最强大的,包含了其他所有排序方式的约束条件。直观上看,顺序一致性操作不能被重排:在同一个线程中,SeqCst 之前的访问永远在它之前,之后的访问永远在它之后。只使用顺序一致性原子操作和数据访问就可以构建一个无数据竞争的程序,这种程序的好处是它的命令在所有线程上都有着唯一的执行流程。而且这个执行流程又很容易推导:它就是每个线程各自执行流程的交叉。如果你使用更弱的原子排序方式的话,这一点并不一定继续有效。
顺序一致性给开发者的便利并不是免费的。即使是在强顺序平台上,顺序一致性也会产生内存屏障 (memory fence)。
事实上,顺序一致性很少是程序正确性的必要条件。但是,如果你对其他内存排序方式模棱两可的话,顺序一致性绝对是你正确的选择。程序执行得稍微慢一点总比执行出错要好!将它变为具有更弱一致性的原子操作也很容易,只要把
SeqCst
变成Relaxed
就完工了!当然,证明这种变化的正确性就是另外一个问题了。
获取 - 释放
获取和释放经常成对出现。它们的名字就提示了它们的应用场景:它们适用于获取和释放锁,确保临界区不会重叠。
直观看起来,acquire 保证在它之后的访问永远在它之后。可在它之前的操作却有可能被重排到它后面、类似的,release 保证它之前的操作永远在它之前。但是它后面的操作可能被重排到它前面。
当线程 A 释放了一块内存空间,紧接着线程 B 获取了同一块内存,这时因果关系就确定了。在 A 释放之前的所有写操作的结果,B 在获取之后都能看到。但是,它们和其他线程之间没有确定因果关系。同理,如果 A 和 B 访问的是不同的内存,它们也没有因果关系。
所以,释放 - 获取的基本用法很简单:你获取一块内存并进入临界区,然后释放内存并离开临界区
use std::sync::Arc; use std::sync::atomic::{AtomicBool, Ordering}; use std::thread; fn main() { let lock = Arc::new(AtomicBool::new(false)); // 我上锁了吗? // ...用某种方式把锁分发到各个线程... // 设置值为true,以尝试获取锁 while lock.compare_and_swap(false, true, Ordering::Acquire) {} // 跳出循环,表明我们获取到了锁! // ...恐怖的数据访问... // 工作完成了,释放锁 lock.store(false, Ordering::Release); }
在强顺序平台上,大多数的访问都有释放和获取的语义,释放和获取通常是无开销的。不过在弱顺序平台上不是这样。
Relaxed
Relaxed 访问是最弱的。它们可以被随意重排,也没有先后关系。但是 Relaxed 操作依然是原子的。也就是说,它并不算是数据访问,所有对它的读 - 修改 - 写操作都是原子的。Relaxed 操作适用于那些你希望发生但又并不特别在意的事情。比如,多线程可以使用 Relaxed 的 fetch_add 来增加计数器,如果你不使用计数器的值去同步其他的访问,这个操作就是安全的。
在强顺序平台上使用 Relaxed 没什么好处,因为它们通常都有释放 - 获取语义。不过,在弱顺序平台上,Relaxed 可以获取更小的开销。
实现
根据之前的理论,我们现在就开始实现自旋锁
我们创建一个新的项目称为system,我们编写的代码最终要以库的形式使用,因此在创建的时候选择创建库(library)而不是可执行(executable)
通过一下命令便可以创建
cargo new system --lib
我们的项目结构为
system
|
|__ src
| |
| |__ lib.rs
|
|__ Cargo.toml
|
|__ .gitignore
我们创建一个src/mutex.rs文件(别忘记在lib.rs中声明模块),然后写入以下内容
use core::cell::UnsafeCell;
use core::sync::atomic::AtomicBool;
struct Mutex<T: ?Sized> {
lock: AtomicBool,
data: UnsafeCell<T>,
}
pub struct MutexGuard<'a, T: ?Sized + 'a> {
lock: &'a AtomicBool,
data: &'a mut T,
}
在Mutex
中我们使用lock
表示是否获得锁,使用data,存储需要同步访问的资源,在这里我们的泛型使用了Sized约束,Sized表示该类型在编译时已经确定大小,结构体中所有参数都必须实现了Sized绑定,特殊语法是?Sized
表示如果绑定不适合使用将会移除,MutexGuard
获取被保护的资源,当我们获取锁时,将会返回MutexGuard
,当MutexGuard的声明周期结束时将会自动释放锁
紧接着我们为Mutex实现几个方法
impl<T> Mutex<T> {
pub const fn new(data: T) -> Mutex<T> {
Mutex {
lock: AtomicBool::new(false),
data: UnsafeCell::new(data),
}
}
pub fn into_runner(self) -> T {
// 注意data的变量名一定要跟Mutex中的成员名一致
// 这里只获取Mutex.data
let Mutex { data, .. } = self;
data.into_inner()
}
}
into_runner
方法将获取data中的原始数据
现在我们开始实现自旋锁
use core::sync::atomic::{AtomicBool, Ordering, spin_loop_hint};
impl<T: ?Sized> Mutex<T> {
fn obtain_lock(&self) {
// 尝试获得锁
while self.lock.compare_and_swap(false, true, Ordering::Acquire) {
// 循环判断是否已经解锁如果没有解锁
while self.lock.load(Ordering::Relaxed) {
// 向处理器发出信号,表明现在处于自旋状态
spin_loop_hint();
}
}
// 跳出循环后表明获得锁
}
pub fn lock(&self) -> MutexGuard<T> {
self.obtain_lock();
MutexGuard {
lock: &self.lock,
data: unsafe { &mut *self.data.get() },
}
}
}
obtain_lock
用于获取锁是私有方法,仅供lock方法使用,当一个线程进入obtain_lock
后会尝试获取锁,如果没获取它将一直在内层循环中不断的判断是否已经解锁lock=false
,为了过度消耗CPU资源我们使用spin_loop_hint
来告诉CPU线程处于自旋状态,spin_loop_hint
使用llvm.x86.sse2.pause
指令来完成,pause
指令向CPU发送自旋信号,CPU收到自旋信号后,处理器可以通过节省电源或切换超线程等优化
lock
为用户调用方法,如果锁获取成功obtain_lock将会执行完毕,最后将原始资源返回
我们提供的函数有些"暴躁"了,如果没获取到会一直获取,我们应该提供一个"温柔"点的方法来尝试获取
pub fn try_lock(&self) -> Option<MutexGuard<T>> {
if self.lock.compare_and_swap(false, true, Ordering::Acquire) == false {
Some(MutexGuard {
lock: &self.lock,
data: unsafe { &mut *self.data.get() },
})
} else {
None
}
}
try_lock
将会判断是否获取到锁,如果获取到返回原始数据,否则返回None
我们获取锁实现了接下来实现解锁操作,我们只要将之前的锁住状态true
改为解锁状态false
impl<'a, T: ?Sized> Drop for MutexGuard<T> {
fn drop(&mut self) {
self.lock.store(false, Ordering::Release);
}
}
之后我们需要实现Deref和DerefMut来完成不可变解引用操作
impl<'a, T: Sized> Deref for MutexGuard<T> {
type Target = T;
fn deref(&self) -> &T {
&*self.data
}
}
impl<'a, T: Sized> DerefMut for MutexGuard<'a, T> {
fn deref_mut(&mut self) -> &mut T { &mut *self.data }
}
unsafe impl<T: ?Sized + Sync> Sync for MutexGuard<T> {}
unsafe impl<T: ?Sized + Sync> Send for MutexGuard<T> {}
我们以后可以使用自旋锁来完成多线程操作,因此实现了Sync和Send
最终我们的mutex.rs文件内容如下
use core::sync::atomic::{AtomicBool, Ordering, spin_loop_hint};
use core::cell::UnsafeCell;
use core::marker::Sync;
use core::ops::{Drop, Deref, DerefMut};
use core::option::Option::{self, None, Some};
use core::default::Default;
// 在编译时已经确定大小
// 所有参数都必须实现了Sized绑定
// 特殊语法是?Sized表示如果绑定不适合使用将会移除
pub struct Mutex<T: ?Sized> {
lock: AtomicBool,
data: UnsafeCell<T>,
}
pub struct MutexGuard<'a, T: ?Sized + 'a> {
lock: &'a AtomicBool,
data: &'a mut T,
}
impl<T> Mutex<T> {
pub const fn new(data: T) -> Mutex<T> {
Mutex {
lock: AtomicBool::new(false),
data: UnsafeCell::new(data),
}
}
pub fn into_runner(self) -> T {
// 注意data的变量名一定要跟Mutex中的成员名一致
// 这里只获取Mutex.data
let Mutex { data, .. } = self;
data.into_inner()
}
}
unsafe impl<T: ?Sized + Sync> Sync for Mutex<T> {}
unsafe impl<T: ?Sized + Sync> Send for Mutex<T> {}
impl<T: ?Sized> Mutex<T> {
fn obtain_lock(&self) {
// 尝试获得锁
while self.lock.compare_and_swap(false, true, Ordering::Acquire) {
// 循环判断是否已经解锁如果没有解锁
while self.lock.load(Ordering::Relaxed) {
// 向处理器发出信号,表明现在处于自旋状态
spin_loop_hint();
}
}
// 跳出循环后表明获得锁
}
pub fn lock(&self) -> MutexGuard<T> {
self.obtain_lock();
MutexGuard {
lock: &self.lock,
data: unsafe { &mut *self.data.get() },
}
}
pub unsafe fn force_unlock(&self) {
self.lock.store(false, Ordering::Release)
}
pub fn try_lock(&self) -> Option<MutexGuard<T>> {
if self.lock.compare_and_swap(false, true, Ordering::Acquire) == false {
Some(MutexGuard {
lock: &self.lock,
data: unsafe { &mut *self.data.get() },
})
} else {
None
}
}
}
impl<T: Sized + Default> Default for Mutex<T> {
fn default() -> Mutex<T> {
Mutex::new(Default::default())
}
}
impl<'a, T: Sized> DerefMut for MutexGuard<'a, T> {
fn deref_mut(&mut self) -> &mut T { &mut *self.data }
}
impl<'a, T: Sized> Deref for MutexGuard<'a, T> {
type Target = T;
fn deref(&self) -> &T {
&*self.data
}
}
impl<'a, T: ?Sized> Drop for MutexGuard<'a, T> {
fn drop(&mut self) {
self.lock.store(false, Ordering::Release);
}
}
改造之前的代码
回到我们的droll_os
项目,我们需要引用我们之前写的库,在Cargo.toml文件中添加如下内容
[dependencies]
system={path="/home/admins/Rust/lib/",version="0.1.0"}
启用system是我们创建的cargo项目,path是我们cargo项目的路径
我们在上一篇中实现的代码是这样子的
// vga.rs
#[allow(dead_code)]
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
// 指定字节对齐方式
#[repr(u8)]
pub enum Color {
// 黑色
Black = 0,
// 蓝色
Blue = 1,
// 绿色
Green = 2,
// 青色
Cyan = 3,
// 红色
Red = 4,
// 品红色
Magenta = 5,
// 棕色
Brown = 6,
// 浅灰色
LightGray = 7,
// 深灰色
DarkGray = 8,
// 浅蓝色
LightBlue = 9,
// 浅绿色
LightGreen = 10,
// 浅青色
LightCyan = 11,
// 亮红色
LightRed = 12,
// 粉色
Pink = 13,
// 黄色
Yellow = 14,
// 白色
White = 15,
}
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
#[repr(transparent)]
pub struct ColorCode(u8);
impl ColorCode {
pub fn new(foreground: Color, background: Color) -> ColorCode { // foreground: 前景色 // background: 背景色
ColorCode((background as u8) << 4 | foreground as u8)
}
}
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
#[repr(C)]
struct ScreenChar {
// ASCII 字符
ascii_char: u8,
// 字符颜色
color: ColorCode,
}
pub struct Buffer {
// 二维数组,使用VGA 模式显示文本
chars: [[Volatile<ScreenChar>; BUFFER_WIDTH]; BUFFER_HEIGHT],
}
// Writer总是以\n结尾
pub struct Writer {
// 当前行号
pub row_position: usize,
// 当前列号
pub column_position: usize,
// 字符颜色
pub color_code: ColorCode,
// 屏幕缓冲区 生命周期位整个程序运行时间
pub buffer: &'static mut Buffer,
}
impl Writer {
pub fn write_bytes(&mut self, byte: u8) {
match byte {
b'\n' => self.new_line(),
byte => {
// 检查是否超过每行最大字符数
if self.column_position >= BUFFER_WIDTH {
// 超过需要换行
self.new_line()
}
let row = self.row_position;
let col = self.column_position;
let color = self.color_code;
// 使用write方法来代替= 保证编译器将永远不会优化写操作。
self.buffer.chars[row][col].write(ScreenChar {
ascii_char: byte,
color,
});
self.column_position += 1;
}
}
}
pub fn write_string(&mut self, s: &str) {
for byte in s.bytes() {
match byte {
//32(空格) - 126(~)
0x20..=0x7e | b'\n' => self.write_bytes(byte),
// 不是ASCII可打印字符 会打印■
_ => self.write_bytes(0xfe),
}
}
}
fn new_line(&mut self) {
// 如果超过最大行数
if self.row_position >= BUFFER_HEIGHT {
// 清空屏幕
self.clear_screen();
self.row_position = 0;
}
self.row_position += 1;
self.column_position = 0;
}
fn clear_screen(&mut self) {
let blank = ScreenChar {
ascii_char: b' ',
color: self.color_code,
};
for row in 0..BUFFER_HEIGHT {
for col in 0..BUFFER_WIDTH {
self.buffer.chars[row][col].write(blank);
}
}
}
}
因此我们使用的时候是这样子的
#![no_std]
#![no_main]
#[macro_use]
extern crate kernel;
use core::panic::PanicInfo;
use kernel::vga::{Writer, ColorCode, Color, Buffer};
#[no_mangle]
pub extern "C" fn _start() -> ! {
let mut w = Writer {
row_position: 0,
column_position: 0,
color_code: ColorCode::new(Color::White, Color::Black),
buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
};
w.write_string("Hello World");
loop{}
}
假设我们在不同的文件中都需要使用打印字符串,这样我们要写很多次这样的代码,所以我们要把Writer声明成静态全局的,要注意的是,writer会被多个任务同时调用(虽然现在没有进程以后会有的)这样打印的字符将会混乱不堪,因此我们使用我们已经实现的自旋锁
所以我们在vga.rs文件中添加一下内容
pub static ref WRITER: Mutex<Writer> = Mutex::new(
Writer {
row_position: 0,
column_position: 0,
color_code: ColorCode::new(Color::White, Color::Black),
buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
});
如果我们现在编译的话会发生错误
calls in statics are limited to constant functions, tuple structs and tuple variants
要了解这里发生的情况,我们需要知道静态变量是在编译时初始化的,而不是在运行时初始化的普通变量,Rust编译器评估此类初始化表达式的组件称为“const evaluator”。它的功能仍然有限,但是现在还在不断地优化,例如“允许常量panic”
这里的根本问题是Rust的const求值器无法在编译时将原始指针转换为引用。因此我们需要找到其他的替代方案
因此我们使用lazy_static,lazy_static定义惰性初始化的静态宏。惰性初始化不会在编译时计算其值,而是在首次访问时会初始化自身
我们在Cargo.toml文件中添加一下内容
[dependencies.lazy_static]
version = "1.0"
features = ["spin_no_std"]
因此我们可以这样初始化我们的代码
use lazy_static::lazy_static;
// static 懒加载无需在编译时计算其值,而是在首次访问时进行初始化
lazy_static! {
// 保证内部可变性是安全的
pub static ref WRITER: Mutex<Writer> = Mutex::new(
Writer {
row_position: 0,
column_position: 0,
color_code: ColorCode::new(Color::White, Color::Black),
buffer: unsafe { &mut *(0xb8000 as *mut Buffer) },
});
}
这样我们就可以使用WRITER
来打印字符了
print!和println!
接下来我们开始去编写print!和prinln!宏我们可以参考一下标准库中的实现
#[macro_export]
#[stable(feature = "rust1", since = "1.0.0")]
#[allow_internal_unstable(print_internals, format_args_nl)]
macro_rules! println {
() => ($crate::print!("\n"));
($($arg:tt)*) => ({
$crate::io::_print($crate::format_args_nl!($($arg)*));
})
}
#[macro_export]
#[stable(feature = "rust1", since = "1.0.0")]
#[allow_internal_unstable(print_internals)]
macro_rules! print {
($($arg:tt)*) => ($crate::io::_print($crate::format_args!($($arg)*)));
}
我们可以看到标准库实现中都会调用crate::io::_print
来完成_print
实现比较复杂因为它们要支持Stdout设备,我们只需要向VGA中打印字符串即可因此我们拷贝这两个宏,并实现自己的_print
// vga.rs
#[macro_export]
macro_rules! println {
() => ($crate::print!("\n"));
($($arg:tt)*) => ({
$crate::vga::print!("{}\n", format_args!($($arg)*));
})
}
#[macro_export]
macro_rules! print {
($($arg:tt)*) => ($crate::vga::_print(format_args!($($arg)*)));
}
#[doc(hidden)]
pub fn _print(arg: fmt::Arguments) {
// 一定要导入Write trait否则会提示没有实现write_fmt方法
use core::fmt::Write;
WRITER.lock().write_fmt(arg).unwrap();
}
我们将#[macro_export]
属性添加到两个宏,以使其在crate中的任何位置都可用
请注意,这会将宏放置在crate的根namespace中,因此无法通过使用crate::vga::println
导入它们。我们必须使用crate::println
来导入即可或者在extern crate <name>
上面添加#[macro_use]
即可
现在在我们的入口函数中就可以这样使用了
#![no_std]
#![no_main]
#[macro_use]
extern crate kernel;
use core::panic::PanicInfo;
#[no_mangle]
pub extern "C" fn _start() -> ! {
println!("Hello World");
loop {}
}
/// 用于运行过程中异常处理
#[panic_handler]
fn panic(info: &PanicInfo) -> ! {
println!("Error: {}",info);
loop {}
}
好了,这样我们就可以使用我们自己实现的print!和println!宏了!
接下来要做什么
在下一章中我们开始编写一些工具函数,常用的位操作,描述符等等(大家加油!)
上一篇: Spring系列之事务管理-16
下一篇: Spring声明式事务