Tarihçe: Go'nun select ifadesi, Gorutinlerin kanal işlemlerini çoklama yapabilmesi için İletişimsel Ardışık Süreçler (CSP) mantığını desteklemek amacıyla tanıtılmıştır. Derleyici, select ifadesini, hazır kanallar arasında seçim yapma ya da birinin hazır olmasını beklemek için karmaşık mantığı yöneten runtime.selectgo çağrılarına düşürmektedir.
Sorun: Yaygın bir yanlış anlama, bir default durumunun eklenmesinin tüm senkronizasyon yükünü ortadan kaldırarak kanal işlemlerini kilitsiz hale getirdiğidir. Bu karmaşa, "engellemeyen" (hiçbir durum hazır değilse hemen dönme) ile "kilitsiz" (mutex çatışmasının olmaması) kavramlarının karıştırılmasından kaynaklanmaktadır.
Çözüm: Aslında, Go'nun kanalları, kanalın başlık yapısı içinde bulunan ince taneli bir mutex (hchan.lock) ile korunmaktadır. select ifadesi gerçekleştirildiğinde, çalışma zamanı, tüm ilgili kanalların kilitlerini alır—ölçekleme sırasına göre bellek adresine göre sıralanmış olarak ölü kilitlenmeleri önlemek için—tam atomik olarak tampon durumlarını ve bekleme kuyruklarını denetlemek amacıyla. Eğer bir default durumu mevcutsa ve hiçbir kanal hazır değilse, çalışma zamanı bu kilitleri serbest bırakır ve derhal döner, böylece gorutin park edilmez. Ancak, mutex edinimi hala gerçekleşir, bu da işlemin kilitsiz olmadığı anlamına gelir. Tersine, tüm durumlar engellendiğinde, çalışma zamanı gorutini park eder, her kanalın bekleme kuyruğuna bir sudog yapısını kuyruğa ekler ve ardından atomik olarak tüm kilitleri serbest bırakıp işlemciyi serbest bırakır.
Bir yüksek frekanslı ticaret firması, merkezi bir dağıtıcı kullanarak select ifadesi ile default durumunu birden çok fiyat akış kanallarını gözetlemek için kullandı ve bu örüntüyü microsanaye ölçeğinde gecikme gereksinimleri için sıfır maliyetli senkronizasyon sağladığı varsayımıyla uyguladı.
Sorun Tanımı: Üretim yükü altında, toplayıcı ara sıra milisaniyeleri aşan gecikme zirveleri gösterdi. CPU profilleme, dağıtıcı gorutininin runtime.lock ve runtime.unlock içinde kanal mutexleri için 35% döngüsünü harcadığını gösterdi. Geliştirme ekibi, "engellemeyen" ile "kilitsiz" kavramlarını yanlış bir şekilde eşitledi ve yüksek frekanslı sorgulama için kanalları senkronizasyon yerine kullandı.
Düşünülen Farklı Çözümler:
Bir yaklaşım, select yapısını korurken ancak kanal tampon boyutlarını 1024 öğeye artırmayı denedi, bu da içerideki çatışmayı azaltmayı umuyordu. Bu, üreticiler için engellemeyi azaltırken, default durumu kontrolü için gereken mutex yüklemesini ortadan kaldırmadı ve sıcak yol dağıtıcıyı hala kilitlerin önbellek tutarlılığı trafiğine maruz bıraktı.
Başka bir çözüm, kanal sorgulamayı tamamen atomic.CompareAndSwapPointer kullanarak kilitsiz bir halka tampon uygulaması ile değiştirdi. Bu, mutex yükünü ortadan kaldırmakta ve okuyucular için beklemeden ilerleme garantileri sağlamakta. Ancak, kod tabanını ciddi şekilde karmaşıklaştırdı ve üreticilerin paylaşılan göstericileri güncellediğinde olası ABA sorunları yaratabilecekti.
Seçilen çözüm, piyasa verilerinin değişmez anlık görüntü yapılarını depolamak için sync/atomic Value kullanıldı. Üreticiler atomik olarak yeni yapılara gösterici değişimleri yaptı ve dağıtıcı sıkı döngüsünde atomik yüklemeler gerçekleştirdi. Bu, finansal tıklama verilerinin "son-değer-kazanır" mantığını mükemmel şekilde eşleyerek tek kelimelik atomiklik ile gerçek kilitsiz okumalar sağladı.
Sonuç: Bu değişiklik, dağıtıcının p99 gecikmesini 800 mikro saniyeden 12 nano saniyeye düşürdü, mutex kaynaklı planlayıcı alışverişlerini ortadan kaldırdı ve genel CPU kullanımını %42 azaltarak sistemin aynı donanımda iki kat daha fazla işlem hacmini yönetmesine olanak tanıdı.
"Neden çalışma zamanı, bir select ifadesinde tüm kanalları aynı anda kilitliyor ve kilit edinim sırasını belirleyen spesifik öngörü engelleme protokolü nedir?"
Go'nun çalışma zamanı, select durumlarını temelindeki hchan yapıların bellek adreslerine göre sıralar ve kilitleri kesinlikle artan adres sırasına göre edinir. Bu küresel toplam sıralama, iki gorutinin örtüşen kanal setlerinde select işlemi yaptığında dairesel bekleme ölü kilitlenmelerini önler. Eğer gorutin A kanal X'i ardından Y'yi kilitlerken, gorutin B Y'yi ardından X'i kilitlerse, bir ölü kilitlenme meydana gelir; adres bazlı sıralama, her iki gorutininin her zaman X'i önce Y'yi kilitleme çabasını sağlamaktadır, dairesel bağımlılığı ortadan kaldırmaktadır.
"Bir default durumunun varlığı, engelleyici bir select ile karşılaştırıldığında çalışma zamanının bellek bariyeri davranışını nasıl değiştirir?"
Bir default içermeyen engelleyici bir select ifadesinde, gorutin kendi bekleme düğümünü (sudog) her kanalın bekleme kuyruğuna yayınlamak zorundadır. Bu, planlayıcının ara durumu gözlemlemesi için bir yazma bariyeri ve bir bellek engeli gerektirir. Bir default durumu ile, gorutin asla park edilmez; basitçe kilit altında durumları denetler ve hemen geri döner. Sonuç olarak, bekleme düğümlerinin yayınlanması ve yeniden başlamada sonrasında önbellek geçersiz kılmayı azaltan bellek bariyeri maliyetlerinden kaçınılır, ancak yine de kanal kilitlerinin senkronizasyon maliyetleri oluşur.
"Özel bir koşul altında, kapasitesi olan bir tamponlu kanalda bir gönderim işlemi hala select ifadesi sırasında nasıl başarısız olabilir?"
Bu, select ifadesinin aynı kanalı referans alan birden fazla durumu içerdiği veya kanalın eşzamanlı olarak kapatıldığı durumlarla ortaya çıkar. Özellikle, select birden fazla gönderim durumunu aynı kanallar üzerinde değerlendirirse, çalışma zamanının sahte rastgele seçimi farklı bir durumu seçebilir, böylece hazır gönderim gerçekleştirilmez. Daha kritik olarak, başka bir gorutin, select'in kilit edinim aşamasında kanalı kapatırsa, bekleyen gönderim, kilitler tutulduğunda kapanmayı algılar ve "kapatılmış kanalda gönderim" ile panik yaparak işlemi normal şekilde tamamlamasını engeller.