From 324d0d4e25ad73003855efff7b54668cefdb7b17 Mon Sep 17 00:00:00 2001
From: vinicius <viniciusmellos@outlook.com.br>
Date: Tue, 19 Mar 2024 16:38:12 -0300
Subject: [PATCH] Write summary for mistake 74

---
 docs/index.md | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/docs/index.md b/docs/index.md
index ca9333b..9969b34 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1950,6 +1950,37 @@ In summary, we have to be careful with the boundaries of a mutex lock. In this s
 
     `sync` types shouldn’t be copied.
 
+The sync types in Go, such as `sync.Mutex` and `sync.WaitGroup`, contain internal state that is used to coordinate the execution of goroutines. If you copy a sync value, you are copying this internal state, which can lead to unexpected behavior and subtle errors.
+
+For example, consider the following code that uses a `sync.Mutex`:
+
+```go
+type MyStruct struct {
+    mu sync.Mutex
+    // other fields...
+}
+
+func (m *MyStruct) Lock() {
+    m.mu.Lock()
+}
+
+func (m *MyStruct) Unlock() {
+    m.mu.Unlock()
+}
+
+func main() {
+    m1 := MyStruct{}
+    m2 := m1 // Copies m1, including the mutex
+
+    m1.Lock()
+    m2.Unlock() // Unlocks a different copy of the mutex!
+}
+```
+
+In this example, `m1` and `m2` have separate mutexes, so `m2.Unlock()` does not unlock the mutex that `m1.Lock()` has locked. This can lead to a deadlock or other race conditions.
+
+Therefore, it is best practice _not to copy_ `sync` values. Instead, pass pointers to these values or avoid the need for copying.
+
  [:simple-github: Source code](https://github.com/teivah/100-go-mistakes/tree/master/src/09-concurrency-practice/74-copying-sync/main.go)
 
 ## Standard Library