Barrier trong Go: bắt nhiều goroutine đồng bước qua sync.Cond

Có những bài toán đồng thời cần các goroutine đồng bước: tất cả phải hoàn thành pha N trước khi bất kỳ ai bắt đầu pha N+1. Ví dụ điển hình: thuật toán lặp song song, mô phỏng vật lý theo bước thời gian — mỗi bước phụ thuộc vào việc mọi worker đã cập nhật xong bước trước. Công cụ cho việc này là barrier (rào chắn): một điểm mà N goroutine cùng chờ tới rồi cùng đi tiếp. Bài này dựng barrier bằng sync.Cond và đo thật tác dụng của nó.

Ba cách dựng barrier trong Go

Go không có kiểu Barrier sẵn, nhưng dựng dễ từ nguyên thủy có sẵn:

• sync.WaitGroup: rào một lần — main chờ tất cả goroutine tới một điểm. Đơn giản nhất, nhưng không đối xứng (worker không chờ nhau, chỉ main chờ).
• channel close: rào một lần dạng broadcast — mọi goroutine chờ <-startCh, rồi close(startCh) mở cho tất cả cùng lúc.
• sync.Cond: rào tuần hoàn (dùng lại nhiều vòng) — mạnh nhất, cho lockstep nhiều pha.

Hình 1: Barrier. Ba cách dựng (WaitGroup/channel/Cond), barrier tuần hoàn bằng sync.Cond với gen counter, channel-barrier một lần, và khi nào cần.

Barrier tuần hoàn bằng sync.Cond

func (b *Barrier) Wait() {
	b.mu.Lock(); defer b.mu.Unlock()
	g := b.gen
	b.count++
	if b.count == b.n {        // người CUỐI tới → mở rào
		b.count = 0; b.gen++
		b.cond.Broadcast()      // đánh thức MỌI goroutine chờ
	} else {
		for g == b.gen {         // chờ tới khi thế hệ đổi (rào mở)
			b.cond.Wait()        // nhả khóa + ngủ, được đánh thức thì lấy lại khóa
		}
	}
}

Cơ chế: mỗi goroutine tới tăng count. Người cuối cùng (count == n) đặt lại count, tăng gen (thế hệ), và Broadcast đánh thức tất cả. Những goroutine tới trước đang Wait trong vòng lặp kiểm g == b.gen — khi gen đổi, chúng thoát. gen làm barrier tuần hoàn: mỗi vòng có một thế hệ mới, nên barrier dùng lại được cho vòng sau. (Lưu ý cond.Wait phải trong vòng for kiểm điều kiện, không phải if — chống spurious wakeup.)

Đo thật: đồng bước vs mất đồng bộ

Cho 4 goroutine tốc độ khác nhau (id × 5ms) chạy 3 vòng:

Hình 2: Có barrier — mỗi vòng đủ 4 goroutine mới qua (đồng bước). Không barrier — goroutine nhanh vượt trước, lệch 2 vòng. Bảng so ba cách dựng.

• Có barrier tuần hoàn: mỗi vòng đều đủ 4 goroutine tới rào rồi mới cùng qua — dù tốc độ khác nhau, barrier ép chúng đồng bước. Không ai sang vòng r+1 tới khi cả 4 xong vòng r.
• Không barrier: khoảng cách vòng lớn nhất giữa các goroutine = 2 — goroutine id=0 (nhanh) đã ở vòng 2 khi id=3 (chậm) còn vòng 0. Mất đồng bộ hoàn toàn.

Nếu vòng sau phụ thuộc dữ liệu vòng trước của MỌI worker (như mô phỏng), việc mất đồng bộ này là bug: goroutine nhanh đọc dữ liệu vòng trước mà worker chậm chưa cập nhật xong.

Ứng dụng thực tế

Thuật toán lặp song song đồng bộ theo pha. Nhân ma trận theo khối, mô phỏng vật lý (mỗi hạt cập nhật theo trạng thái toàn cục bước trước), thuật toán đồ thị lặp — mọi worker phải xong pha hiện tại trước khi ai bắt đầu pha sau. Barrier giữ đúng ngữ nghĩa này.

Khởi động đồng loạt cho benchmark. Khi đo N goroutine song song, dùng channel-barrier (close(start)) để chúng bắt đầu cùng một khoảnh khắc — nếu goroutine đầu chạy trước khi goroutine cuối được tạo, phép đo lệch. Đây là mẫu chuẩn trong benchmark đồng thời.

Chọn barrier theo nhu cầu dùng lại. Cần một pha đồng bộ: WaitGroup hoặc channel đủ. Cần nhiều pha lặp lại: dùng barrier tuần hoàn (sync.Cond) để không phải tạo mới mỗi vòng. Đừng dùng Cond khi WaitGroup đủ — nó phức tạp hơn.

Đánh đổi cần cân nhắc

Barrier ép tốc độ về goroutine chậm nhất. Bản chất của đồng bước: mọi worker chờ người chậm nhất ở mỗi rào. Nếu tải không cân (một worker luôn chậm), barrier lãng phí thời gian các worker nhanh. Cân nhắc chia tải đều hơn, hoặc dùng mô hình khác (work-stealing) nếu đồng bước không thật sự cần — barrier chỉ đáng khi đúng đắn đòi hỏi nó.

sync.Cond khó dùng đúng, dễ sai. Cond là nguyên thủy cấp thấp: phải nhớ Wait trong vòng for (không phải if), giữ khóa đúng cách, và Broadcast vs Signal. Nhiều bug đồng thời đến từ dùng Cond sai. Nếu channel hoặc WaitGroup diễn đạt được, ưu tiên chúng — Cond chỉ khi thật cần barrier tuần hoàn hoặc điều kiện chờ phức tạp.

Barrier không chịu lỗi tốt. Nếu một goroutine chết (panic) trước khi tới rào, các goroutine khác chờ mãi mãi — deadlock (như bài trước). Barrier production cần cơ chế: context timeout, hoặc đếm goroutine còn sống và điều chỉnh n. Đừng dùng barrier "trần" nơi worker có thể thất bại.

Ba ý mang về

1. Barrier bắt N goroutine cùng tới rào rồi cùng đi tiếp (đồng bước): đo thật, 4 goroutine tốc độ khác nhau vẫn đồng bộ từng vòng với barrier tuần hoàn — không ai sang vòng r+1 tới khi cả 4 xong vòng r; không barrier, goroutine nhanh vượt trước lệch tới 2 vòng.
2. Ba cách dựng theo nhu cầu: sync.WaitGroup (rào một lần, main chờ), channel close (broadcast một lần, mở cho tất cả cùng lúc), sync.Cond (barrier tuần hoàn dùng lại qua gen counter với Broadcast + Wait) — chọn Cond chỉ khi cần nhiều pha lặp lại.
3. Barrier ép tốc độ về goroutine chậm nhất và không chịu lỗi tốt: nó đáng khi đúng đắn đòi hỏi đồng bước (thuật toán lặp song song, mô phỏng, khởi động benchmark đồng loạt) — nhưng sync.Cond khó dùng đúng (Wait trong for), và một goroutine chết trước rào gây deadlock, nên cần timeout/context ở production.

Bài tập làm thử

Bài 1 (đọc hiểu). Cho cài đặt barrier tuần hoàn bằng sync.Cond:

func (b *Barrier) Wait() {
	b.mu.Lock(); defer b.mu.Unlock()
	g := b.gen
	b.count++
	if b.count == b.n {
		b.count = 0; b.gen++
		b.cond.Broadcast()
	} else {
		for g == b.gen {
			b.cond.Wait()
		}
	}
}

Biến gen (thế hệ) dùng để làm gì? Nếu bỏ biến gen và chỉ dùng for b.count != 0 để chờ, barrier có còn dùng lại được cho nhiều vòng không?

Bài 2 (sửa lỗi). Đoạn mã sau dùng sync.Cond sai một điểm quan trọng đã được bài nhắc tới. Tìm lỗi và sửa.

func (b *Barrier) Wait() {
	b.mu.Lock(); defer b.mu.Unlock()
	g := b.gen
	b.count++
	if b.count == b.n {
		b.count = 0; b.gen++
		b.cond.Broadcast()
	} else {
		if g == b.gen { // <-- lỗi ở đây
			b.cond.Wait()
		}
	}
}

for g == b.gen {
	b.cond.Wait()
}

Bài 3 (vận dụng thực tế). Bạn cần chạy một benchmark với 8 goroutine, muốn tất cả bắt đầu công việc đo tại đúng cùng một thời điểm (không goroutine nào chạy trước trong khi các goroutine khác còn đang được tạo). Bạn nên dùng cách dựng barrier nào trong ba cách (WaitGroup, channel close, sync.Cond) và tại sao?

Bài 4 (đọc số liệu đo thật). Bài đo thật cho 4 goroutine tốc độ khác nhau (id × 5ms) chạy 3 vòng: có barrier thì mọi vòng đều "đủ 4 goroutine mới qua"; không có barrier thì khoảng cách vòng lớn nhất giữa các goroutine là 2 (goroutine nhanh đã ở vòng 2 trong khi goroutine chậm còn vòng 0). Nếu thuật toán của bạn có vòng sau phụ thuộc dữ liệu vòng trước của MỌI worker, việc bỏ barrier gây ra hậu quả gì cụ thể?

Bài 5 (bẫy/đánh đổi). Bài viết cảnh báo "barrier không chịu lỗi tốt". Giải thích cụ thể điều gì xảy ra nếu một trong N goroutine bị panic trước khi gọi Wait(), và nêu một cách giảm thiểu rủi ro này ở môi trường production.

Phần sau ta chuyển sang đo lường chính vấn đề đồng thời đã gặp nhiều lần: Phần sau mổ xẻ mutex profile — cách dùng runtime.SetMutexProfileFraction và pprof để đo tranh chấp khóa thật trong chương trình, tìm mutex nào là nút thắt.