Sinkronisasi on Nalar

Fencing Token Menutup Celah Writer dari Lease Kedaluwarsa

Sat, 19 Sep 2026 00:00:00 +0000

Lease terdistribusi dapat kedaluwarsa ketika pemegangnya tidak dapat berjalan. Pemegang tersebut kemudian dapat aktif lagi dengan state lokal yang masih menyatakan bahwa lease dimilikinya, padahal client lain sudah memperoleh lease yang lebih baru. Jika storage atau service yang dilindungi menerima operasi hanya karena client pernah memperoleh lease, dua client dapat memutasi resource yang sama pada titik waktu berbeda.

Fencing token memindahkan pemeriksaan penentu dari kepemilikan lease ke resource yang dilindungi. Setiap akuisisi yang berhasil memperoleh token yang berurutan setelah semua token sebelumnya. Resource mencatat token terbesar yang pernah diterima dan menolak operasi dengan nilai lebih lama. Lease tetap mengoordinasikan akuisisi, sedangkan token membatasi tindakan pemegang lama yang terlambat setelah kembali aktif.

Sequence Counter Mendeteksi Write Konkuren Tanpa Lock pada Reader

Sat, 19 Sep 2026 00:00:00 +0000

Sequence counter dapat memungkinkan reader menyalin shared state tanpa mengambil lock milik writer. Reader mengambil nilai counter, menyalin field yang dilindungi, lalu mengambil nilai counter sekali lagi. Nilai genap yang sama pada kedua observasi menandakan tidak ada writer yang overlap dengan proses penyalinan berdasarkan kontrak sinkronisasi. Nilai yang berubah atau ganjil memaksa reader membuang snapshot dan mengulang operasi.

Pola ini memindahkan pekerjaan dari kepemilikan lock pada sisi reader, tetapi tidak menghapus sinkronisasi. Writer tetap memerlukan serialisasi, transisi counter memerlukan semantik memory ordering yang terdefinisi, dan data yang dilindungi harus tetap aman diakses selama write yang overlap. Constraint tersebut membuat sequence counter cocok untuk sebagian snapshot yang dominan dibaca, tetapi tidak aman untuk data yang lifetime-nya dapat berakhir saat reader masih mengaksesnya.

Go sync.Cond Wait Memeriksa Ulang Shared State

Wed, 16 Sep 2026 00:00:00 +0000

sync.Cond.Wait melanjutkan eksekusi setelah notification, tetapi notification tidak menyatakan bahwa kondisi khusus milik caller masih true ketika goroutine memperoleh lock kembali. Shared predicate tetap menjadi source of truth, sehingga waiter memeriksanya lagi setiap kali Wait kembali.

Boundary ini memisahkan notification dari state. Signal dan Broadcast mengumumkan bahwa state yang relevan mungkin telah berubah; keduanya tidak memindahkan ownership state tersebut atau memesannya untuk waiter tertentu.

Wait membuka lock lalu memperolehnya kembali

Sebuah Cond terkait dengan Locker, umumnya *sync.Mutex. Caller memegang lock tersebut saat memeriksa shared state. Jika predicate false, Wait secara atomik membuka locker dan menangguhkan caller. Sebelum Wait kembali, ia mengunci locker lagi.

Reuse Go WaitGroup Memerlukan Boundary Wait yang Sudah Selesai

Wed, 16 Sep 2026 00:00:00 +0000

sync.WaitGroup dapat digunakan kembali setelah sebuah wait phase selesai, tetapi task set independen baru tidak boleh dimulai selama call Wait dari phase sebelumnya masih aktif. Boundary-nya adalah return dari setiap Wait sebelumnya, bukan sekadar saat internal task counter mencapai nol.

Constraint ini penting ketika satu instance WaitGroup dipertahankan lintas batch, epoch, request wave, atau coordination cycle berulang. Reuse didukung, tetapi phase tidak boleh overlap pada transisi counter dari nol menjadi positif.