diff --git a/docs/labs/0x01/tasks.md b/docs/labs/0x01/tasks.md
index 2b344a7..a5f6a56 100644
--- a/docs/labs/0x01/tasks.md
+++ b/docs/labs/0x01/tasks.md
@@ -447,9 +447,37 @@ char read_serial() {
 
 #### 串口驱动的测试
 
-在 `pkg/kernel/src/utils/macros.rs` 中，你可以找到 `print!` 和 `println!` 宏面向串口输出的实现。
+在 `pkg/kernel/src/utils/macros.rs` 中，你可以找到 `print!` 和 `println!` 宏面向串口输出的实现：
 
-在调用 `drivers::serial::init()` 后，如果能够正常看到 `[+] Serial Initialized.` 的输出，说明串口驱动已经成功初始化。
+```rust
+#[macro_export]
+macro_rules! print {
+    ($($arg:tt)*) => (
+        $crate::utils::print_internal(format_args!($($arg)*))
+    );
+}
+
+#[doc(hidden)]
+pub fn print_internal(args: Arguments) {
+    interrupts::without_interrupts(|| {
+        if let Some(mut serial) = get_serial() {
+            serial.write_fmt(args).unwrap();
+        }
+    });
+}
+```
+
+因此，按照预期，在调用 `drivers::serial::init()` 后，如果能够正常看到 `[+] Serial Initialized.` 的输出，说明串口驱动已经成功初始化。
+
+!!! question "为什么在输出时使用 `get_serial()` 获取串口？"
+
+    在内核中，为了确保串口不会同时被多方“一起访问”，需要用互斥锁来保护串口的访问。
+
+    `get_serial()` 函数尝试获取串口的互斥锁，如果获取成功，则返回一个 `MutexGuard`，这个 `MutexGuard` 将会在离开作用域时自动释放互斥锁。
+
+    然而，与 `get_serial_for_sure()` 更加强势，如果无法获取直接 panic，不留余地，这通常用于“必须获取到，否则是异常”的情况。
+
+    **对于前者的情况，如果在已经获取了串口的互斥锁之后，依然尝试进行 `print!` 输出，将会导致对应的输出内容被忽略，因为串口已经被占用。**
 
 ### 日志输出
 
diff --git a/docs/labs/0x02/tasks.md b/docs/labs/0x02/tasks.md
index c35bb44..93d0419 100644
--- a/docs/labs/0x02/tasks.md
+++ b/docs/labs/0x02/tasks.md
@@ -596,6 +596,14 @@ fn receive() {
 
 你需要补全 `receive` 函数，利用刚刚完成的 `input` 驱动，将接收到的字符放入缓冲区。
 
+!!! warning "中断导致的“并发访问”"
+
+    或许你会困惑：只有一个 CPU，为什么会导致并发访问，进而导致死锁的产生？就算暂时无法获取锁，等待一会也能获取到吧？
+
+    这里需要区分一些概念，与常见的用户态“多线程”的并发不同，中断所导致的“并发访问”是**强制性**的，并且需要**主动恢复**，循环等待的过程**并不存在抢占**。
+
+    **基于上述信息，结合思考题 3 给出的例子，尝试描述锁操作、中断的相关过程，完成该思考题。**
+
 ## 用户交互
 
 在完善了输入缓冲区后，可以在 `src/main.rs` 中，使用 `get_line` 函数来获取用户输入的一行数据，并将其打印出来、或进行更多其他的处理，实现响应用户输入的操作。