Oylamayı seviyorum! Ben mi Evet! Ben mi Evet! Ben mi Evet! Hala mı Evet! Peki ya şimdi? Evet!
Diğerlerinin de belirttiği gibi, yalnızca aynı değişmemiş durumu tekrar tekrar geri almak için anket yaparsanız, inanılmaz derecede verimsiz olabilir. Bu, CPU çevrimlerini yakmak ve mobil cihazlarda pil ömrünü önemli ölçüde kısaltmak için bir reçetedir. Elbette, her seferinde istenenden daha hızlı olmayan bir oranda yeni ve anlamlı bir durum elde ediyorsanız, israf olmaz.
Ancak anket yapmayı sevdiğim ana sebep sadeliği ve tahmin edilebilir doğasıdır. Kod boyunca izleyebilir ve ne zaman ve nerede olayların olacağını ve hangi konudaki konuları kolayca görebilirsiniz. Teorik olarak, yoklamanın ihmal edilebilir bir atık olduğu bir dünyada yaşıyor olsaydık (gerçekliğin ondan uzak olmasına rağmen), kodun çok büyük bir anlaşmayı korumayı kolaylaştıracağına inanıyorum. Ve bu durumda olmamamız gerekse de performansı göz ardı edip edemeyeceğimizi gördüğüm gibi oy kullanmanın ve çekmenin yararı bu.
DOS döneminde programlamaya başladığımda, küçük oyunlarım oylama etrafında dönüyordu. Bazı montaj kodlarını, klavye kesintileriyle ilgili zorlukla anladığım bir kitaptan kopyaladım ve ana halimin her zaman sorgulayacağı bir klavye durumu tamponu depolamasını sağladım. Yukarı tuşu aşağı mı? Hayır! Yukarı tuşu aşağı mı? Hayır! Şimdi nasıl? Hayır! Şimdi? Evet. Tamam, oynatıcıyı oynat.
İnanılmaz derecede boşa giderken, bu çok görevli ve etkinlik odaklı programlamaya kıyasla aklınıza gelmesi çok daha kolay. Her zaman ne zaman ve nerede olacağını tam olarak biliyordum ve kare hızlarını hiccup olmadan istikrarlı ve öngörülebilir tutmak daha kolaydı.
O zamandan beri, CPU döngülerini gerçekten yakmadan, bazı avantajları ve öngörülebilirliğini elde etmenin bir yolunu bulmaya çalıştım, örneğin, yeni durumu hangi noktada uyandırmaları gerektiğini bildiren konuları bildirmek için koşul değişkenleri kullanmak gibi, işlerini yap ve tekrar haber bekliyorum uyu.
Ve her nasılsa olay sıralarını en azından gözlemci modelleriyle çalışmaktan çok daha kolay buluyorum, yine de nereye gideceğinizi ya da neyin sona ereceğini tahmin etmeyi o kadar kolay hale getirmese de. En azından olay işleme kontrol akışını sistemdeki birkaç kilit alana merkezileştirir ve bir olaydan tamamen uzak bir yere sıçramak yerine bu olayları her zaman aynı iş parçasında tutar ve merkezi olay işleme iş parçasının aniden dışında beklenmedik bir şekilde bekler. Dolayısıyla, ikilik her zaman gözlemciler ve oylama arasında olmak zorunda değildir. Olay sıraları orada bir çeşit orta yol.
Ama evet, bir şekilde, yıllar önce oylama yaparken kullandığım tahmin edilebilir kontrol akışlarının türüne yakın olan şeyleri yapan sistemler için mantıklı olmanın çok daha kolay olduğunu düşünüyorum. durum değişikliği olmadığı zamanlar. Dolayısıyla, işlem değişkenlerini, koşul değişkenleri gibi gereksiz bir şekilde yazmayan bir şekilde yapabiliyorsanız, bu fayda var.
Homojen Döngüler
Pekala, Josh Caswellcevabımdaki bazı saçmalıklara dikkat çeken harika bir yorum aldım :
"uyanmak üzere konuları bildirmek için koşul değişkenleri kullanmak gibi" Yoklama değil, olay tabanlı / gözlemci düzenlemesi gibi görünüyor
Teknik olarak, koşul değişkeninin kendisi, ipleri uyandırmak / bildirmek için gözlemci modelini uygulamaktır; bu nedenle, "oylama" muhtemelen inanılmaz derecede yanıltıcı olacaktır. Ancak, DOS günlerinden sorgulama olarak bulduğum benzer bir fayda sunduğunu düşünüyorum (sadece kontrol akışı ve öngörülebilirlik açısından). Daha iyi açıklamaya çalışacağım.
O günlerde dikkatimi çeken şey, bir kod bölümüne bakabilmeniz ya da izleyebilmeniz ve "Tamam, tüm bu bölüm klavye olaylarını işlemeye adanmış. Kodun bu bölümünde başka hiçbir şey olmayacaktı. Ve daha önce ne olacağını tam olarak biliyorum ve sonrasında tam olarak ne olacağını biliyorum (örneğin fizik ve render). Klavye durumlarının oylanması, bu harici olaya yanıt olarak ne yapılması gerektiğiyle ilgili olarak kontrol akışının bu tür bir merkezileşmesini sağladı. Bu dış olaya hemen cevap vermedik. Size uygun olan şekilde cevap verdik.
Bir Gözlemci desenine dayanan itme tabanlı bir sistem kullandığımızda, genellikle bu avantajları kaybediyoruz. Bir resize olayını tetikleyen bir kontrol yeniden boyutlandırılabilir. Bunu takip ettiğimizde, yeniden boyutlandırmada daha fazla olay tetikleyen birçok özel şey yapan egzotik kontrolün içinde olduğumuzu görüyoruz. Sistemin neresinde olduğumuzla ilgili tüm bu basamaklı olayları takip ederken tamamen şaşırıyoruz. Ayrıca, tüm bunların, herhangi bir iş parçacığında tutarlı bir şekilde meydana gelmediğini görebiliriz, çünkü iş parçacığı A burada bir denetimi yeniden boyutlandırabilirken, iş parçacığı B daha sonra bir denetimi yeniden boyutlandırır. Bu yüzden, her şeyin nerede olacağını ve ne olacağını tahmin etmenin ne kadar zor olduğunu göz önünde bulundurarak bunu her zaman zor buldum.
Olay sırası benim için biraz daha basit, çünkü bu şeylerin en azından bir iş parçacığında nerede gerçekleştiğini kolaylaştırıyor. Ancak, birçok farklı şey olabilir. Bir olay kuyruğu, işlenecek olayların eklektik bir karışımını içerebilir ve her biri bizi hangi olayların meydana geldiği, işlenme sırasını ve kod tabanındaki her yere nasıl sıçradığımızla ilgili bizi hala şaşırtabilir. .
Oy vermeye "en yakın" olduğunu düşündüğüm şey bir olay kuyruğu kullanmayacak, ancak çok homojen bir işleme türünü erteleyecek. Bir PaintSystempencerenin belirli ızgara hücrelerini yeniden boyamak için boyama işi yapılması gereken bir durum değişkeni ile uyarılmış olabilir, bu noktada hücreler arasında basit bir sıralı döngü yapar ve içindeki her şeyi uygun z sırayla yeniden boyar. Yeniden boyanması gereken bir hücrede bulunan her widget'taki boyama olaylarını tetiklemek için burada tek bir düzeyli dolaylı / dinamik gönderme olabilir, ancak bu - dolaylı çağrıların sadece bir katmanı. Koşul değişkeni, PaintSystemyapması gereken işleri olduğunu bildirmek için gözlemci düzenini kullanır , ancak bundan daha fazlasını hiçbir şey belirtmez.PaintSystemBu noktada bir üniforma, çok homojen bir göreve adamıştır. Hata ayıklama ve PaintSystem'skodu takip ederken , resim dışında başka hiçbir şeyin olmayacağını biliyoruz.
Bu yüzden, çoğunlukla, olay sırasındaki işlemlerle alabileceğimiz sayısız sorumluluk alan farklı veri türleri üzerindeki homojen olmayan döngüler yerine, üzerine çok tekil bir sorumluluk uygulayan veriler üzerinde homojen döngüler yapan bu şeylerin bulunduğu yere gitmenizle ilgilidir.
Bu tür bir şeyi hedefliyoruz:
when there's work to do:
for each thing:
apply a very specific and uniform operation to the thing
Aksine:
when one specific event happens:
do something with relevant thing
in relevant thing's event:
do some more things
in thing1's triggered by thing's event:
do some more things
in thing2's event triggerd by thing's event:
do some more things:
in thing3's event triggered by thing2's event:
do some more things
in thing4's event triggered by thing1's event:
cause a side effect which shouldn't be happening
in this order or from this thread.
Ve bunun gibi. Ve görev başına bir iplik olmak zorunda değildir. Bir iş parçacığı GUI denetimleri için mizanpajlar (yeniden boyutlandırma / yeniden konumlandırma) mantığı uygulayabilir ve bunları yeniden boyayabilir, ancak klavye veya fare tıklamaları ile ilgilenmeyebilir. Böylece, buna bir olay sırasının homojenliğini iyileştirmek için bakabilirsiniz. Ancak bir olay sırası kullanmak zorunda değiliz ve yeniden boyutlandırma ve boyama işlevlerini birleştirelim. Biz yapabiliriz:
in thread dedicated to layout and painting:
when there's work to do:
for each widget that needs resizing/reposition:
resize/reposition thing to target size/position
mark appropriate grid cells as needing repainting
for each grid cell that needs repainting:
repaint cell
go back to sleep
Bu yüzden yukarıdaki yaklaşım sadece yapılması gereken iş olduğunda ipliği bildirmek için bir koşul değişkeni kullanır, ancak farklı olay türlerini birleştirmez (bir döngüde yeniden boyutlandır, başka bir döngüde boya, her ikisinin karışımı değil) ve İşin tam olarak yapılması gereken şeyin ne olduğunu bildirmekten rahatsız olmayın (iş parçacığı, ECS'nin sistem genelindeki durumlarına bakarak uyandıktan sonra bunu "keşfeder"). Gerçekleştirdiği her döngü daha sonra doğada çok homojendir, bu da her şeyin gerçekleştiği sıraya göre karar vermeyi kolaylaştırır.
Bu tür bir yaklaşıma ne diyeceğimi bilmiyorum. Başka GUI motorlarının bunu yaptığını görmedim ve bu benimkine kendi egzotik yaklaşımım. Fakat gözlemcileri veya olay kuyruklarını kullanarak çok iş parçacıklı GUI çerçevelerini uygulamaya koymaya başladığımda, hata ayıklama konusunda muazzam bir zorluk yaşadım ve kendimi güvende hissettirecek şekilde düzeltmek için yeterince akıllı olmadığım bazı belirsiz yarış koşullarına ve çıkmaza girdim çözüm hakkında (bazı insanlar bunu yapabilir olabilir ama yeterince akıllı değilim). İlk yineleme tasarımım doğrudan bir sinyal yoluyla doğrudan bir yuva olarak adlandırıldı ve bazı yuvalar daha sonra zaman uyumsuzluk çalışması için diğer iş parçacıkları ortaya çıkardı ve bu akla gelmesi en zor olan şeydi ve yarış koşulları ve çıkmazlar yüzünden takılıyordum. İkinci yineleme bir olay kuyruğu kullandı ve bunun nedeni biraz daha kolaydı. ama beynimin hala belirsiz çıkmaza girme ve yarış koşullarına girmeden yapması için yeterince kolay değil. Üçüncü ve son yineleme, yukarıda açıklanan yaklaşımı kullandı ve sonunda benim gibi aptal bir bastonun bile doğru bir şekilde uygulayabileceği çok iş parçacıklı bir GUI çerçevesi oluşturmamı sağladı.
Daha sonra bu son derece iş parçacıklı GUI tasarımı, aklıma gelmek için çok daha kolay olan ve yapma eğiliminde olduğum bu türden hatalardan kaçınmak için çok daha kolay olan başka bir şey bulmama izin verdi. en azından bu homojen döngülerden kaynaklanıyorlar ve DOS günlerinde oylama yaptığım zamana benzer şekilde kontrol akışına benziyorlardı (gerçekten oylama yapmıyor ve sadece yapılacak işler varken iş yapıyor olsalar bile). Fikir, homojen olmayan döngüler, homojen olmayan yan etkiler, homojen olmayan kontrol akışları ve homojen veri üzerinde homojen bir şekilde çalışan homojen döngülere doğru daha fazla çalışmak için olay işleme modelinden mümkün olduğunca uzağa hareket etmekti. ve yan etkilerin sadece "neye" odaklanmayı kolaylaştıran şekillerde birleştirilmesi