From a2ac8156e6bbe19c92c472a44424596a22d43a15 Mon Sep 17 00:00:00 2001
From: noQils <daffaaqilmahmud@gmail.com>
Date: Thu, 27 Mar 2025 15:45:06 +0700
Subject: [PATCH] add Reflection Subscriber-1

---
 README.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.md b/README.md
index 7e0fc90..e8d0638 100644
--- a/README.md
+++ b/README.md
@@ -85,5 +85,12 @@ This is the place for you to write reflections:
 ### Mandatory (Subscriber) Reflections
 
 #### Reflection Subscriber-1
+### 1. Why is `RwLock<>` necessary, and why not use `Mutex<>`?
+
+In this tutorial, we used `RwLock<>` to synchronize access to the `Vec` of notifications. The main reason for using `RwLock<>` instead of `Mutex<>` is performance optimization in a concurrent environment. `RwLock<>` allows multiple readers to access the data simultaneously while ensuring that only one writer can modify the data at any given time. This is useful in scenarios where reads are more frequent than writes, as it prevents unnecessary blocking. If we had used `Mutex<>`, every read operation would require exclusive access to the lock, blocking other readers and leading to performance bottlenecks. With `RwLock<>`, multiple threads can read the notifications concurrently without interfering with each other, while still maintaining exclusive access when modifications are necessary.
+
+### 2. Why does Rust not allow mutating the content of a static variable like in Java?
+
+In Java, static variables are stored in a shared memory space, and their contents can be modified freely through static functions. Rust, however, enforces strict ownership and borrowing rules to prevent data races and ensure memory safety at compile time. A `static` variable in Rust has a fixed memory location and must be immutable unless explicitly wrapped in synchronization primitives like `Mutex<>` or `RwLock<>`. The reason for this restriction is that, in a multi-threaded environment, direct mutation of a static variable without synchronization could lead to undefined behavior, such as data races. Rust’s approach forces developers to explicitly handle synchronization, ensuring thread safety and memory correctness. This design makes Rust safer by preventing unintended modifications and enforcing concurrency safety at the language level.
 
 #### Reflection Subscriber-2
-- 
GitLab