From 45e61eb1040744549fc43f5868d7dfcf93a2585e Mon Sep 17 00:00:00 2001 From: Laura Ruse Date: Thu, 30 Nov 2023 14:44:52 +0200 Subject: [PATCH] Update synchronization.md Fixed typo --- content/chapters/compute/lab/content/synchronization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/chapters/compute/lab/content/synchronization.md b/content/chapters/compute/lab/content/synchronization.md index b299b21a4e..6e94f76d82 100644 --- a/content/chapters/compute/lab/content/synchronization.md +++ b/content/chapters/compute/lab/content/synchronization.md @@ -52,7 +52,7 @@ When a thread calls `pthread_mutex_lock()`, it attempts to set that variable to If it was 0, the thread sets it to 1 and proceeds to execute the critical section. Otherwise, it **suspends its execution** and waits until that variable is set to 0 again. -When calling `pthread_mute_unlock()`, the internal variable is set to 0 and all waiting threads are woken up to try to acquire the mutex again. +When calling `pthread_mutex_unlock()`, the internal variable is set to 0 and all waiting threads are woken up to try to acquire the mutex again. **Be careful:** It is generally considered unsafe and [in many cases undefined behaviour](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html) to call `pthread_mutex_unlock()` from a different thread than the one that acquired the lock. So the general workflow should look something like this: