add mutex section to concurrency

.vitepress/config.mts

@@ -248,6 +248,7 @@ export default defineConfig({
           items: [
             { text: 'Wait Groups', link: '/concurrency/wait-groups' },
             { text: 'Atomicity', link: '/concurrency/atomicity' },
+            { text: 'Mutexes', link: '/concurrency/mutexes' },
             { text: 'Threads', link: '/concurrency/threads' },
           ],
         },

src/concurrency/atomicity.md

@@ -36,18 +36,18 @@ use std::sync::atomic::{AtomicInt, MemoryOrder}
 
 static mut n: AtomicInt = AtomicInt.new(0)
 
-fn add_to_n(mut wg: *WaitGroup) {
-    unsafe defer { wg.done() }
+fn add_to_n(mut wg: &WaitGroup) {
+    defer { wg.done() }
     n.add(1, MemoryOrder.Relaxed)
 }
 
 fn main() {
-    let mut wg = WaitGroup{}
+    let mut wg = WaitGroup.new()
 
     let mut j = 0
     for j < 1000000; j++ {
         wg.add(1)
-        co add_to_n(&wg)
+        co add_to_n(wg)
     }
 
     wg.wait()

src/concurrency/mutexes.md

@@ -0,0 +1,67 @@
+# Mutexes
+
+In the previous section, atomics were explained and when atomicity was required was mentioned. When it comes to shared data, atomicity may not always be a solution or may be insufficient. For example, if you are working with a data type that is not atomically supported, or if your algorithm needs safe execution, atomic types will not be enough to solve your problem.
+
+For example:
+```jule
+use std::sync::{WaitGroup}
+
+static mut n = 0
+
+fn add_to_n(mut wg: &WaitGroup) {
+    defer { wg.done() }
+    outln("incrementing")
+    n++
+    outln("incremented")
+}
+
+fn main() {
+    let mut wg = WaitGroup.new()
+
+    let mut j = 0
+    for j < 1000000; j++ {
+        wg.add(1)
+        co add_to_n(wg)
+    }
+
+    wg.wait()
+    outln(n)
+}
+```
+
+In the above code, not only the value of `n` variables is manipulated, but some functions are also called. Atomic types are not a good approach in such cases.
+
+To solve this problem we can use a mutex. Mutexes are locking mechanisms that allow you to do this. They can only be locked by a single thread at a time. If a locking attempt is made by a different thread when they are locked, the execution of the thread will be stopped until the locking thread releases the lock.
+
+For example:
+
+```jule
+use std::sync::{WaitGroup, Mutex} // [!code ++]
+
+static mut n = 0
+static mtx = Mutex.new() // [!code ++]
+
+fn add_to_n(mut wg: &WaitGroup) {
+    defer { wg.done() }
+    mtx.lock() // [!code ++]
+    outln("incrementing")
+    n++
+    outln("incremented")
+    mtx.unlock() // [!code ++]
+}
+
+fn main() {
+    let mut wg = WaitGroup.new()
+
+    let mut j = 0
+    for j < 1000000; j++ {
+        wg.add(1)
+        co add_to_n(wg)
+    }
+
+    wg.wait()
+    outln(n)
+}
+```
+
+In the code above, synchronization between threads is achieved by using mutex. Thanks to Mutex, only one thread can continue executing the relevant function at a time, and the others are waiting to take over the lock. This means that another thread cannot continue execution until one thread has completely completed its execution. In this way, race condition is prevented.

src/concurrency/wait-groups.md

@@ -30,7 +30,6 @@ fn say_hello(mut wg: &WaitGroup) {
 
 fn main() {
     let mut wg = WaitGroup.new()
-
     wg.add(1)
     co say_hello(wg)
     wg.wait()

src/std/sync.md

@@ -15,6 +15,9 @@ in each parallel job:\
 
 **Methods:**
 
+`static fn new(): &WaitGroup`\
+Returns new WaitGroup instance.
+
 `fn add(mut self, delta: int)` \
 Increments (+delta) or decrements (-delta) task count by delta and unblocks any wait() calls if task count becomes zero. Panics if task count reaches below zero.