Designing a game that utilizes the Readers$-$Writers synchronization problem can be an interesting and challenging task for you. As we have seen in the last class, the Readers$-$Writers problem is often used to manage access to shared data where multiple readers can access the data simultaneously, but only one writer should have exclusive access to this shared resource.

The conceptual scenario of this game where the Readers$-$Writers synchronization problem could be applied is as follows:

Game Elements: You have tree elements in this game.

$1.$ Dungeon Data $($Shared Resource$)$:

o Represents the state of the dungeon, including room layouts, enemy positions, and treasure locations.

$2.$ Players $($Readers$)$:

o Multiple players explore the dungeon concurrently.

o Players can view the current state of the dungeon.

$3.$ Game Master $($Writer$)$:

o Controls the overall state of the dungeon.

o Modifies the dungeon layout, moves enemies, and updates treasure locations.

Implementation:

$1.$ Readers $($Players$)$:

o Players can read $($view$)$ the current state of the dungeon simultaneously.

o Multiple players can explore different parts of the dungeon concurrently without interfering with each other.

$2.$ Writer $($Game Master$)$:

o The Game Master has exclusive write access to the dungeon data.

o When the Game Master makes modifications $($e$.$g$.,$ changes the layout, moves enemies, updates treasures$),$ it must ensure that no player is reading the data at that moment.

$3.$ Readers$-$Writers Synchronization:

o Use a mutex to protect access to the dungeon data $($the shared data$).$

o When a player wants to view the dungeon state, it acquires the read lock.

o When the Game Master wants to modify the dungeon state, it acquires the write lock.

o Readers can access the dungeon data concurrently as long as no writer has the write lock.

o If a writer has the write lock, no readers or other writers can access the data.

$4.$ Avoiding Starvation:

o Implement a fair solution to avoid starvation.

o Use condition variables to signal waiting readers or writers when the lock becomes available.

Your Task: you have to complete the missing part at hw$4.$c by adding the appropriate lock, unlock, cond$\_$wait and cond$\_$signal to the code. I have put TODO to indicate that part is missing.

The output of the program of $3$ players can be as follows:

husam@istinye:~$ $./$a$.$out

Player $1$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $1$ explores the dungeon. $($Treasures: $5,$ Enemies: $3)$

Player $1$ finishes reading. $($Readers: $0,$ Writers: $0)$

Player $3$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $3$ explores the dungeon. $($Treasures: $5,$ Enemies: $3)$

Player $3$ finishes reading. $($Readers: $0,$ Writers: $0)$

Player $2$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $2$ explores the dungeon. $($Treasures: $5,$ Enemies: $3)$

Player $2$ finishes reading. $($Readers: $0,$ Writers: $0)$

Game Master $0$ starts writing. $($Readers: $0,$ Writers: $1)$

Game Master $0$ updates the dungeon. $($Treasures: $3,$ Enemies: $1)$

Game Master $0$ finishes writing. $($Readers: $0,$ Writers: $0)$

Player $1$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $1$ explores the dungeon. $($Treasures: $3,$ Enemies: $1)$

Player $1$ finishes reading. $($Readers: $0,$ Writers: $0)$

Player $2$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $2$ explores the dungeon. $($Treasures: $3,$ Enemies: $1)$

Player $2$ finishes reading. $($Readers: $0,$ Writers: $0)$

Player $3$ starts reading. $($Readers: $1,$ Writers: $0)$

Player $3$ explores the dungeon. $($Treasures: $3,$ Enemies: $1)$

Player $3$ finishes reading. $($Readers: $0,$ Writers: $0)$

Game Master $0$ starts writing. $($Readers: $0,$ Writers: $1)$

Game Master $0$ updates the dungeon. $($Treasures: $7,$ Enemies: $0)$

Game Master $0$ finishes writing. $($Readers: $0,$ Writers: $0)$

Player $1$ starts reading. $($Readers: $1,$ Writers: $0)$