compute/synchronization: Add link to the lab 8 archives and fix typos

- Add links to the lab archive and change directory references.
- Fix typo in `tls-on-demand` TODO.

Signed-off-by: Vlad Hosu <[email protected]>

Author: vladhsu

chapters/compute/overview/reading/lab8.md

@@ -0,0 +1 @@
+The contents of the lab are located in the [lab archive](https://github.com/cs-pub-ro/operating-systems/raw/refs/heads/lab-archives/Lab_8_Synchronization.zip) and in the [GitHub repository](https://github.com/cs-pub-ro/operating-systems).

chapters/compute/synchronization/drills/tasks/apache2-simulator-condition/README.md

@@ -22,8 +22,8 @@ There are a few rules though, such as:
 - The consumer must not retrieve data if the buffer is empty.
 - The producer and the consumer can't access the shared buffer at the same time.
 
-Now enter `chapters/compute/synchronization/drills/tasks/apache2-simulator-condition/` and run `make skels`.
-Look at the code in `chapters/compute/synchronization/drills/tasks/apache2-simulator/support/src/producer_consumer.py`.
+Now enter the `apache2-simulator-condition/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/apache2-simulator-condition/` if you are working directly in the repository) and run `make skels`.
+Look at the code in `support/src/producer_consumer.py`.
 We have one producer and one consumer for simplicity.
 Observe that the producer calls `notify()` once there is data available, and the consumer calls `notify()`, when data is read.
 Notice that this call is preceded by an `acquire()` call, and succeeded by a `release()` call.
@@ -58,7 +58,7 @@ Neat!
 So now we have both synchronization **and** signalling.
 This is what conditions are for, ultimately.
 
-Open `chapters/compute/synchronization/drills/tasks/apache2-simulator/support/src/apache2_simulator_condition.py` and follow the TODOs.
+Open the `apache2-simulator-condition/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/apache2-simulator-condition/` if you are working directly in the repository), then go to `support/src/apache2_simulator_condition.py` and follow the TODOs.
 The code is similar to `apache2_simulator_semaphore.py`, but this time we use condition variables as shown in `producer_consumer.py`.
 
 [Quiz](../../../drills/questions/notify-only-with-mutex.md)

chapters/compute/synchronization/drills/tasks/atomic-assembly/README.md

@@ -11,14 +11,14 @@ It is not an instruction with its own separate opcode, but a prefix that slightl
 For example, we cannot place it before a `mov` instruction, as the action of a `mov` is simply `read` or `write`.
 Instead, we can place it in front of an `inc` instruction if its operand is memory.
 
-Go in `chapters/compute/synchronization/drills/tasks/atomic-assembly/` and run:
+Go in the `atomic-assembly/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/atomic-assembly/` if you are working directly in the repository) and run:
 
 ```bash
 make skels
 ```
 
-Look at the code in `chapters/compute/synchronization/drills/tasks/atomic-assembly/support/src/race_condition_lock.asm`.
-It's an Assembly equivalent of the code you've already seen many times so far (such as `chapters/compute/synchronization/drills/tasks/race-condition/support/c/race_condition.c`).
+Look at the code in `support/src/race_condition_lock.asm`.
+It's an Assembly equivalent of the code you've already seen many times so far (such as `race-condition/support/c/race_condition.c`).
 The 2 assembly functions (**increment_var** and **decrement_var**) are called by `race_condition_lock_checker.c`
 
 Now add the `lock` prefix before `dec`.

chapters/compute/synchronization/drills/tasks/race-condition-atomic/README.md

@@ -13,7 +13,7 @@ Modern processors are capable of _atomically_ accessing data, either for reads o
 An atomic action is an indivisible sequence of operations that a thread runs without interference from others.
 Concretely, before initiating an atomic transfer on one of its data buses, the CPU first makes sure all other transfers have ended, then **locks** the data bus by stalling all cores attempting to transfer data on it.
 This way, one thread obtains **exclusive** access to the data bus while accessing data.
-As a side note, the critical sections in `chapters/compute/synchronization/drills/tasks/race-condition/support/c/race_condition_mutex.c` are also atomic once they are wrapped between calls to `pthread_mutex_lock()` and `pthread_mutex_unlock()`.
+As a side note, the critical sections in `race-condition/support/c/race_condition_mutex.c` are also atomic once they are wrapped between calls to `pthread_mutex_lock()` and `pthread_mutex_unlock()`.
 
 As with every hardware feature, the `x86` ISA exposes an instruction for atomic operations.
 In particular, this instruction is a **prefix**, called `lock`.
@@ -27,19 +27,19 @@ Compilers provide support for such hardware-level atomic operations.
 GCC exposes [built-ins](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html) such as `__atomic_load()`, `__atomic_store()`, `__atomic_compare_exchange()` and many others.
 All of them rely on the mechanism described above.
 
-Go to `chapters/compute/synchronization/drills/tasks/race-condition-atomic/` and run:
+Go to the `race-condition-atomic/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/race-condition-atomic/` if you are working directly in the repository) and run:
 
 ```bash
 make skels
 ```
 
-Now enter `chapters/compute/synchronization/drills/tasks/race-condition-atomic/support/src/race_condition_atomic.c` and complete the function `decrement_var()`.
+Now enter `support/src/race_condition_atomic.c` and complete the function `decrement_var()`.
 Compile and run the code.
 Its running time should be somewhere between `race_condition` and `race_condition_mutex`.
 
 The C standard library also provides atomic data types.
 Access to these variables can be done only by one thread at a time.
-Go to `chapters/compute/synchronization/drills/tasks/race-condition-atomic/support/race_condition_atomic2.c`, compile and run the code.
+Go to `support/src/race_condition_atomic2.c`, compile and run the code.
 
 After both tasks are done, go in the checker folder and run it using the following commands:
 

chapters/compute/synchronization/drills/tasks/race-condition/README.md

@@ -1,6 +1,6 @@
 # C: Race Conditions
 
-Go to `chapters/compute/synchronization/drills/tasks/race-condition/support/c/race_condition_mutex.c` and notice the differences between this code and the buggy one.
+Go to the `race-condition/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/race-condition/` if you are working directly in the repository), then open `support/c/race_condition_mutex.c` and notice the differences between this code and the buggy one.
 We now use a `pthread_mutex_t` variable, which we `lock` at the beginning of a critical section, and we `unlock` at the end.
 Generally speaking, `lock`-ing a mutex makes a thread enter a critical section, while calling `pthread_mutex_unlock()` makes the thread leave said critical section.
 Therefore, as we said previously, the critical sections in our code are `var--` and `var++`.

chapters/compute/synchronization/drills/tasks/threadsafe-data-struct/README.md

@@ -1,7 +1,7 @@
 # Synchronization - Thread-Safe Data Structure
 
 Now it's time for a fully practical exercise.
-Go to `chapters/compute/synchronization/drills/tasks/threadsafe-data-struct/support/`.
+Go to the `threadsafe-data-struct/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/threadsafe-data-struct/` if you are working directly in the repository), then open the `support/` folder.
 In the file `clist.c` you'll find a simple implementation of an array list.
 Although correct, it is not (yet) thread-safe.
 

chapters/compute/synchronization/drills/tasks/tls-on-demand/README.md

@@ -4,7 +4,7 @@ The perspective of C towards TLS is the following: everything is shared by defau
 This makes multithreading easier and more lightweight to implement than in other languages, like D, because synchronization is left entirely up to the developer, at the cost of potential unsafety.
 
 Of course, we can specify that some data belongs to the TLS, by preceding the declaration of a variable with `__thread` keyword.
-Enter `chapters/compute/synchronization/drills/tasks/tls-on-demand/` and run `make skels`.
+Enter the `tls-on-demand/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/tls-on-demand/` if you are working directly in the repository) and run `make skels`.
 Now enter `support/src` and follow the TODOs.
 
 1. Create the declaration of `var` and add the `__thread` keyword to place the variable in the TLS of each thread.

chapters/compute/synchronization/drills/tasks/tls-on-demand/solution/src/race_condition_tls.c

@@ -36,7 +36,7 @@ void *decrement_var(void *arg)
 		var--;
 
 	/**
-	 * Print the value of `var` after it's incremented. Also print
+	 * Print the value of `var` after it's decremented. Also print
 	 * the ID of the thread. Use `pthread_self()` to get it.
 	 */
 	/* TODO 1: */

chapters/compute/synchronization/drills/tasks/wrap-the-for/README.md

@@ -1,6 +1,6 @@
 # Wrap the Whole `for` Statements in Critical Sections
 
-Navigate to the `chapters/compute/synchronization/drills/tasks/wrap-the-for/` directory, run `make skels` and open the `support/src` directory.
+Navigate to the `wrap-the-for/` directory of the extracted archive (or `chapters/compute/synchronization/drills/tasks/wrap-the-for/` if you are working directly in the repository), run `make skels`, and open the `support/src` directory.
 
 Here you will find two source files:
 

config.yaml

@@ -111,6 +111,7 @@ lab_structure:
   - title: Lab 8 - Synchronization
     filename: lab8.md
     content:
+      - reading/lab8.md
       - tasks/race-condition.md
       - tasks/wrap-the-for.md
       - tasks/race-condition-atomic.md