From 54859986856f2e1024a31e3f04ea914a9d2cf2de Mon Sep 17 00:00:00 2001
From: Andrew4Coding <andrewdevitoaryo@gmail.com>
Date: Fri, 28 Mar 2025 12:13:04 +0800
Subject: [PATCH] docs: add first reflection

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

diff --git a/README.md b/README.md
index 7e0fc90..8d43d46 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,13 @@ You can install Postman via this website: https://www.postman.com/downloads/
 This is the place for you to write reflections:
 
 ### Mandatory (Subscriber) Reflections
+> In this tutorial, we used RwLock<> to synchronise the use of Vec of Notifications. Explain why it is necessary for this case, and explain why we do not use Mutex<> instead?
+
+RwLock<> is necessary in this case because we need to allow multiple readers to access the Vec of Notifications concurrently while ensuring that only one writer can modify it at a time. This is important for performance, as it allows multiple threads to read notifications without blocking each other. On the other hand, using Mutex<> would block all readers when a writer is modifying the data, which could lead to performance bottlenecks in scenarios with high read concurrency.
+
+> In this tutorial, we used lazy_static external library to define Vec and DashMap as a “static” variable. Compared to Java where we can mutate the content of a static variable via a static function, why did not Rust allow us to do so?
+
+Rust enforces strict ownership and borrowing rules to ensure memory safety and prevent data races. Unlike Java, where static variables can be mutated directly via static functions, Rust requires explicit synchronization mechanisms like `RwLock<>` or `Mutex<>` to safely mutate shared static data. This design choice ensures that access to shared data is always thread-safe, even in concurrent environments. By using libraries like `lazy_static`, we can initialize static variables in a controlled manner while adhering to Rust's safety guarantees.
 
 #### Reflection Subscriber-1
 
-- 
GitLab