Tarihçe.
sync/atomic paketi, donanım talimatlarına derlenen kilitsiz ilkelere sahiptir. Go 32-bit sistemlere (x86-32, ARM32) taşındığında, çalışma zamanı hizalanmamış 64-bit atomik erişim için yerel desteği olmayan işlemcilerle karşılaştı. Erken sürümler, rastgele hizalamaya izin verdi ve bu da otobüs hatalarına veya sessiz veri bozulmalarına neden oldu. Taşınabilirliği sağlamak için, Go ekibi, atomic işlevlerinin çalıştığı herhangi bir 64-bit değerin adresinin 32-bit mimarilerde 8 bayt hizalı olması gerektiğini zorunlu kıldı.
Problem.
Eğer bir programcı 8 bayt barındırmayan bir int64 işaretçisi geçirirse - örneğin, bir yapının içinde 4 ofsetinde bir alan - atomik işlem bunu çalışma zamanında tespit eder. 32-bit sürümlerde çalışma zamanı hemen programı unaligned 64-bit atomic operation hatasıyla durdurur. Bu sert hata, atomiklik garantilerini ihlal edecek zarar görmüş okumaları veya yazmaları önler.
Çözüm.
Go derleyicisi, yapı alanlarını doğal boyutlarına göre otomatik olarak hizalar, ancak geliştiricilerin yine de alanları doğru bir şekilde sıralaması gerekir: int64 alanlarını yapının başına yerleştirin veya diğer 8 baytlık türlerin ardında olduklarından emin olun. Alternatif olarak, atomic.Int64 kullanın (25. Go sürümünden itibaren mevcut), bu değerleri kapsülleyerek tip sistemi aracılığıyla hizalama garantisi sağlar. Küresel değişkenler için bağlayıcı, doğru hizalamayı sağlar.
tip Metrics struct { // toplamak, 32-bit'te 8 bayt hizalamayı garanti etmek için ilk sıraya yerleştirilmiştir. sum int64 count int32 } func (m *Metrics) Add(v int64) { // 32-bit ve 64-bit mimarilerde güvenlidir. atomic.AddInt64(&m.sum, v) }
Senaryo.
32-bit ARM Cortex-A7 üzerinde çalışan bir IoT geçidi hizmeti, telemetri topladı. Başlangıçta yapı, 64-bit EnergyCounter öncesinde 32-bit DeviceID yerleştiriyordu. Yüksek verimli gorutinler atomic.AddInt64(&device.EnergyCounter, delta) çağrısını yaptı. Dağıtım hemen ardından, hizmet runtime error: unaligned 64-bit atomic operation hatasıyla çökmesiyle sonuçlandı çünkü EnergyCounter 4 ofsetinde bulunuyordu.
Değerlendirilen Çözümler.
Yapı alanlarını yeniden sırala.
int64 alanlarını yapının en üstüne taşımak, ofset 0 hizalamasını garanti eder. Bu yaklaşım ekstra bellek tüketmez ve “en büyük alanlar önce” düzenine uyar. Dezavantajı, DeviceID'nin kaynak kodunda artık ilk sırada görünmeyecek olması nedeniyle hafif bir mantıksal gruplama kaybıdır.
Açık dolgu ekle.
EnergyCounter öncesinde 4 baytlık bir pad int32 alanı eklemek, doğru hizalamayı zorlar. Bu yöntem açık ve kendini belgeleyen bir yapıdadır ancak yapı başına 4 bayt boşa harcar. Her bir cihaz için milyonlarca kayıtla, bu aşırı yük, gömülü flaş depolaması için önemsiz hale geldi.
atomic.Int64 kullan.
Alanı atomic.Int64 sarmalayıcı türüne dönüştürmek, hizalama sorunlarını ortadan kaldırır çünkü tür kendisi 8 baytlık bir hizalama gereksinimi taşır. Ancak, atomic.AddInt64(&d.EnergyCounter, v) çağrı noktasından d.EnergyCounter.Add(v)'ye geçiş yapmayı gerektirdiği için, test edilmemiş kod yollarında geri dönüş riskini artırmaktadır.
Seçilen Çözüm.
Ekip alanları yeniden sıralama (Çözüm 1) seçeneğini tercih etti. 64-bit sayaçların tamamını yapının başına yerleştirerek hizalama elde ettiler ve bellek aşırı yükü veya API değişiklikleri olmadan bunu başardılar. Bu, Go atasözüne uygun: "Daha büyük alanları daha küçüklerin önüne koyun." Gelecekteki gerilemeleri önlemek için CI'ye fieldalignment linter'ı eklediler.
Sonuç.
Panik, tüm ARM32 filosu boyunca kayboldu. Hizmet, atomik ile ilgili çökme olmaksızın iki yıl boyunca çalıştı ve yapı düzeni optimizasyonu kalan alanların daha iyi paketlenmesi nedeniyle bellek ayak izini %8 oranında azalttı.
atomic.LoadInt64 64-bit mimarilerde hizalanmamış adreslerde neden başarılı olurken 32-bit'te paniğe neden oluyor?
64-bit mimarilerde (amd64, arm64), donanım bellek yönetim ünitesi 64-bit değerlere hizalanmamış erişimi destekler, ancak bu, bir performans cezası gerektirebilir. Atomik talimatlar (örneğin, x86-64 üzerindeki MOVQ), hizalanmamış verilere hata vermez. Tersine, 32-bit mimariler, belirli bir 64-bit atomik talimat gerektiren eşleştirilmiş 32-bit kayıtlar kullanır (örneğin, ARM32 üzerindeki LDREXD/STREXD), aksi takdirde bir donanım hizalama hatası oluşturur; bu durumu Go çalışma zamanı fatal “unaligned 64-bit atomic operation” hatasına çevirir.
Bir kullanıcı tanımlı yapının içinde atomic.Int64 iç içe geçirildiğinde 32-bit sistemlerde manuel dolgu olmadan nasıl hizalama garantisi sağlar?
atomic.Int64 tipi, bir int64 içeren bir yapı olarak tanımlanır. Go derleyicisi, bir yapı için hizalama gereksinimini, alanlarının maksimum hizalamasına eşit olarak atar. int64 8 baytlık hizalama gerektirir, bu yüzden atomic.Int64 bu gereksinimi devralır. Bir alan olarak iç içe geçirildiğinde, derleyici, alanın ofsetinin 8'in katı olmasını sağlamak için gerekli olan önceki dolgu baytlarını ekler. Ayrıca, yığın tahsisleri, boyutu türün hizalamasına yuvarlar, bu nedenle iç içe geçmiş alanın bir işaretçisi her zaman 8 bayt hizalamalıdır.
Bir []byte'ı []int64'e unsafe casting ile dönüştürmek neden 32-bit mimarilerde hizalama paniklerine yol açabilir, hatta dilim uzunluğu yeterli olsa bile?
Bir []byte, bir byte dizisi ile desteklenmektedir. Bu dizinin temel adresinin byte erişimi için hizalanması garanti edilir (1 bayt hizalaması), ancak 8 bayt erişimi için garanti edilmez. İşaretçiyi *int64'e dönüştürmek veya []int64 olarak yeniden dilimlemek için unsafe kullanıldığında, ilk öğe 0x1001 gibi bir adreste bulunabilir ki bu da 8'e bölünemez. &int64Slice[0]'ı atomic.LoadInt64'e geçmek, hizalama kontrolünü tetikler. Güvenli dönüşüm, orijinal byte diliminin hizalanmış bir kaynaktan tahsis edildiğinden emin olmayı gerektirir (örneğin, yazmak için make([]int64, ...) aracılığıyla ve []byte'a casting yaparak) veya hizalanmış bir tampon için copy kullanılarak yapılmalıdır.