Go'daki sync/atomic paketi, basit primitiflerden kilitsiz algoritmaların temelini oluşturan kapsamlı bir sıralı tutarlı işlem setine evrimleşmiştir. Go 1.19'dan önce, bellek modeli belgeleri değişkenler arası sıralama konusunda daha az netti, bu da derleyici sıralaması ve goroutine'ler arası görünürlük konusunda yaygın bir kafa karışıklığına yol açtı. atomic.Value'nın tanıtılması, atomik işaretçi güncellemeleri için tür güvenli bir mekanizma sağladı, ancak dahili uygulaması, doğrudan sayısal işlemler yerine unsafe.Pointer değişimlerine dayanıyor, bu da farklı görünürlük semantikaları oluşturuyor ve matematiksel atomiklerden temelde farklılık gösteriyor.
Geliştiriciler genellikle atomik tam sayıların kilitsiz doğasını atomic.Value'nın dolaylı işleme ile karıştırıyor, bu da değişken duruma işaretçiler depolandığında ince veri yarışlarına yol açıyor. atomic.AddInt64 ve benzeri fonksiyonlar, belirli bir bellek kelimesi için sıralı tutarlılık sağlarken—yazmaların, katı bir öncelik sırası içinde sonraki yüklemeler için görünür olmasını sağlıyor—atomic.Value yalnızca arayüz kelimesinin atomikliğine odaklanıyor (tip tanımlayıcı ve veri işaretçisi çifti). Önemli bir şekilde, atomic.Value depolanan değerin derin değişmezliğini garanti etmez; yalnızca okuma işleminin yazma anında depolanan işaretçi ve tip tanımlayıcısının tutarlı bir anlık görüntüsünü gözlemlemesini sağlar, bunun ötesinde işaret edilen yapının içindeki alanların tamamen yayınlandığını garanti etmez.
Atomik tam sayı işlemleri, o belirli değişken üzerindeki tüm işlemlerin toplam bir sıralamasını oluşturur, bu da atomik erişimle ilgili çevredeki bellek işlemlerinin derleyici ve CPU yeniden sıralamasını önleyen senkronizasyon noktaları olarak işlev görür. Buna karşın, atomic.Value, yapılandırma yapılarını kilitsiz güncellemeler için özel olarak tasarlanmıştır: yazar, tüm yapı işaretçi atomik olarak değiştirir ve okuyucular o işaretçiyi kilitsiz olarak alır. Doğru yayınlama için yazar, Store öncesinde yapının tamamen inşa edilmiş olduğundan emin olmalıdır ve okuyucular döndürülen değeri değişmez olarak ele almalı veya dikkatlice kopyalamalıdır. Bu desen, canlı paylaşılan bellek yerine anlık görüntü izolasyonu sağlamaktadır ve sayaç artırmaları ile yapılandırma değişimleri arasında net bir mimari ayrım gerektirmektedir.
Dakikada milyonlarca isteği işleyen dağıtılmış bir oran sınırlayıcı hizmetinde, bir sıcak yol goroutine'i mevcut QPS'yi temsil eden küresel bir sayacı güncellerken, bağımsız arka plan goroutine'leri periyodik olarak yapılandırma ayarlarının tamamını değiştiriyor—limitler, zaman pencereleri ve geri çekilme kurallarını içeren karmaşık bir yapı. Bu senaryo, güncellemeler sırasında gecikme dalgalanmalarını önlemek için sayaç için yüksek verimli atomik artışlar ile birlikte tutarlı, kilitsiz okumalar gerektiriyordu ve senkronizasyon mekanizmaları arasında gerilim yarattı.
Öncelikle yapılandırmayı bir sync.RWMutex içinde paketlemeyi değerlendirdik, bu da QPS sayacını tutarlılık için korumayı zorunlu kılacaktı. Bu yaklaşım, basitlik sağladı ve yapılandırma yapısını karmaşık yerinde değiştirmelere izin verdi. Ancak, mutex 64 çekirdekli dağıtımımızda ciddi bir darboğaz haline geldi; her sayaç artışı, kilidi almak gerektiğinden, yıkıcı önbellek satırı sıçramalarına ve p99 gecikme dalgalanmalarının on mikro saniyeyi aşmasına neden oldu, bu da hizmet düzeyi hedeflerimizi ihlal etti.
Sayaç için atomic.AddUint64 kullanmaya geçtik, bu da gerçekte kilitsiz artışları mümkün kıldı ve çekirdek sayısına göre lineer olarak ölçeklendi. Yapılandırma için, arka plan goroutine'lerinin güncellemeleri yayınlamasına izin veren atomic.Value içinde değişmez bir Config yapısına işaretçi sakladık; yeni bir tam yapı oluşturarak ve Store'u çağırarak. Bu, okuma tarafında kilitlenmeyi tamamen ortadan kaldırdı, ancak sık güncellemeler, bellek tahsis baskısı ve GC döngüsünü artırdı, bu nedenle atık üretimini azaltmak ve atomik anlık görüntü semantiklerini sürdürmek için ön tahsis edilmiş bir yapılandırma nesneleri halkası gerektirdi.
Üçüncü bir seçenek olarak, atomic.Value üzerinde yer alan arayüzün kutu üzerinden geçiş yükünü önlemek için unsafe.Pointer ile atomic.LoadPointer ve StorePointer kullanmayı prototipledik. Bu yaklaşım, ön tahsis edilmiş bir yapılandırma havuzu kullanıldığında sıfır tahsisatlı depolamaları mümkün kıldı, teorik olarak verimliliği maksimize etti. Ancak, runtime.KeepAlive aracılığıyla atık toplama canlılığının titiz yönetimini gerektirdi ve tamamen tür güvenliğini kaybederek, sistemi bellek bozulması ve sessiz veri yarışı risklerine maruz bıraktı, bu da üretim trafiği için kabul edilemezdi.
Sonuçta, milyonlarca işlem başına saniye için gereken verimliliği sağlaması sayesinde Seçenek 2'yi seçtik; atomik sayaç, taraflar arası ya da kernel geçişleri olmadan gereken verimliliği sağladı. atomic.Value deseni, yapılandırma için kilitsiz anlık görüntü okumaları sağladı, orta düzeydeki güncelleme sıklığı göz önüne alındığında güvenlik ve performans arasında en iyi dengeyi sağladı. Bu mimari, sıcak yol için p99 gecikmelerinde kırk katlık bir azalma ile sonuçlandı, on iki mikro saniyeden üç yüz nano saniyeye düştü ve tüm goroutine'ler arasında tutarlı yapılandırma görünürlüğünü garanti etti.
Soru 1: Eğer Goroutine A, paylaşılan bir atomik olmayan değişken x'e yazarsa, ardından atomic.StoreUint64(&flag, 1) işlemini yaparsa ve Goroutine B flag'ı atomic.LoadUint64(&flag) aracılığıyla okur ve değeri 1 olarak gözlemler, Goroutine B, A tarafından yapılan x yazmasını görecek mi?
Cevap:
Evet, ama sadece Go'nun bellek modelindeki sıralı tutarlı atomikler tarafından belirlenen özel happens-before ilişkisi nedeniyle. A'daki atomik depo, değeri gözlemleyen B'deki atomik yük ile senkronize oluyor, yani depo yükten önce gerçekleşiyor. Çünkü x'e yazma, atomik depodan önce gelir ve atomik yük, B tarafından yapılacak sonraki herhangi bir okuma işleminden önce gerçekleşir, dolayısıyla x'e yazma ile B'nin x'i okuması arasında geçişli bir happens-before bağlantısı vardır.
Ancak, bu garanti, B'nin gerçekten atomik yükü gerçekleştirmesi ve yazmayı gözlemlemesi şartına bağlıdır; eğer B, A depolamadan önce değeri kontrol ederse veya A, atomik depodan sonra x'e yazmayı yeniden sıralarsa (derleyici sıralı tutarlılık nedeniyle bunu yapamaz), görünürlük kaybolur. Adaylar genellikle atomiklerin yalnızca değişkeni etkilediğini veya tersine, tüm değişkenlerin tüm goroutine'ler için büyülü bir şekilde görünür hale geldiğini düşünerek bu sıkı senkronizasyon zincirinin gerekliliğini anlamazlar.
Soru 2: Neden atomic.Value, Store argümanının nil türsüz bir arayüz olmaması gerektiğini zorunlu kılıyor (yani, v.Store(nil) çalıştırıldığında hata verir) ve bu, türlü nil işaretçiyi depolamaktan nasıl farklıdır?
Cevap:
atomic.Value, bir arayüzün tür tanımlayıcısı ve veri kelimesini ifade eden bir [2]uintptr depolar. Store(nil) çağrısı yaptığında, derleyici nil arayüz değerinin somut tipini belirleyemez, bu da geçerli bir tür tanımlayıcı kelimeye ihtiyacı olan nil bir tür tanımlayıcısı kelimesi ortaya çıkarır; bu nedenle hata verir.
Buna karşın, var p *MyStruct = nil; v.Store(p) ifadesi, türlü bir nil sağlar; burada tür tanımlayıcısı *MyStruct ve veri kelimesi sıfırdır. Bu ayrım, Go'nun çalışma zamanı arayüz işleme ve yansıma için kritiktir; adaylar sıklıkla bir atomic.Value'yi türetilmemiş nil ile temizlemeye çalışır ve çalışma zamanı hatalarıyla karşılaşır, tür bilgisinin, içsel invariyantları sürdürmek için nil değerler için bile korunması gerektiğini fark etmeden.
Soru 3: Neden bir yapı göstericisini saklamak için atomic.Value kullandığımızda, okuyucu yine de yapı içindeki alanlarda bayat verileri gözlemleyebilirken, atomik yük yeni işaretçi değerini döner?
Cevap:
atomic.Value, yalnızca işaretçi değişiminin atomikliğini garanti eder, depo öncesinde yapı içeriğinin inşa edilme sırasını garanti etmez. Eğer yazar, işaretçiyi yayımlamadan önce yapı alanlarını tamamen oluşturmadan önce (örneğin, alanlara Store öncesinde yazıyorsa), okuyucu yeni işaretçi adresini görebilir ancak önbellek ya da kısmen yazılmış alan değerlerini okuyabilir, çünkü yazıcının talimatları derleyici ve CPU tarafından yeniden sıralanabilir.
Doğru desen, yazarın değişmez yapıyı tamamen inşa etmesini gerektirir (işaretçi kaçmadan önce tüm alanların yazılması) veya daha yeni Go versiyonlarında mevcut olan kesin serbest bırakma semantikleriyle atomic.Pointer kullanmasını gerektirir. Adaylar genellikle atomic.Value tarafından belirlenen happens-before ilişkisinin yalnızca işaretçi kelimesinin yayılmasını kapsadığını, o işaretçi aracılığıyla ulaşılabilir geçiş verisinin, uygun yapı inşa disiplini korunmadıkça nihai olarak bayatlamış olabileceğini gözden kaçırır, bu da üretimde ince ve nadir veri yarışlarına yol açar.