it-swarm-tr.com

Çoklu iş parçacığının neden zor olduğunu açıklama

Oldukça iyi bir programcıyım, patronum da oldukça iyi bir programcı. Çok iş parçacığı ve ne kadar zor olabileceği gibi bazı görevleri hafife alıyor gibi görünse de (birkaç iş parçacığı çalıştırmaktan, herkesin bitmesini bekledikten sonra sonuçları döndürmekten daha zor bir şey buluyorum).

Kilitlenmeler ve yarış koşulları hakkında endişelenmeye başladığınız anda, bunu çok zor buluyorum, ama patron bunu takdir etmiyor gibi görünüyor - bununla hiç karşılaşmadığını sanmıyorum. Sadece bir kilit tokat hemen hemen tutum budur.

Peki onu nasıl tanıtabilirim ya da eşzamanlılık, paralellik ve çoklu iş parçacığının karmaşıklıklarını neden hafife alıyor olabileceğini açıklayabilirim? Ya da belki yanılıyorum?

Düzenleme: Yaptığı şeyden biraz - bir liste boyunca döngü yapın, bu listedeki her öğe için o öğedeki bilgilere dayanarak bir veritabanı güncelleme komutu yürüten bir iş parçacığı oluşturun. Bir kerede kaç tane iş parçacığının nasıl kontrol edildiğinden emin değilim, sanırım çok fazla çalışan (onları bir semafor kullanmaz) bir kuyruğa eklemiş olmalı.

86
Mr Shoubs
  1. Herhangi bir matematiksel deneyime güvenebiliyorsanız, temel olarak deterministik olan normal bir yürütme akışının sadece birkaç iş parçacığı ile belirsiz olmadığını değil, üstel olarak karmaşık olduğunu gösterin, çünkü makine talimatlarının olası her harmanlanmasını sağlamanız gerekir hala doğru olanı yapacak. Kayıp bir güncelleme veya kirli okuma durumuna basit bir örnek genellikle göz açıcıdır.

  2. "Üzerine bir kilit tokat" is önemsiz çözüm ... tüm sorunları çözer eğer performans konusunda endişe duymuyorsunuz. Örneğin, Atlanta'da bir kişi bir kitap sipariş ettiğinde Amazon'un tüm doğu kıyılarını kilitlemesi gerekiyorsa, performansın ne kadar olacağını göstermeye çalışın!

29
Kilian Foth

Çoklu iş parçacığı is basit. Bir uygulamayı çoklu iş parçacığı için kodlamak çok, çok kolaydır.

Basit bir hile var ve bu, iş parçacıkları arasında veri aktarmak için iyi tasarlanmış bir mesaj kuyruğu kullanmak (do not kendiniz döndürmeyin).

Zor kısım, paylaşılan bir nesneyi sihirli bir şekilde bir şekilde güncellemek için birden fazla iş parçacığına sahip olmaya çalışıyor. İşte o zaman hataya açık hale gelir, çünkü insanlar mevcut yarış koşullarına dikkat etmezler.

Birçok kişi mesaj kuyrukları kullanmaz ve paylaşılan nesneleri güncellemeye ve kendileri için sorun oluşturmaya çalışır.

Zor olan şey, verileri birkaç kuyruk arasında geçirirken iyi çalışan bir algoritma tasarlamaktır. Bu zor. Ancak birlikte varolan iş parçacıklarının mekaniği (paylaşılan kuyruklar aracılığıyla) kolaydır.

Ayrıca, iş parçacıklarının paylaş G/Ç kaynakları olduğuna dikkat edin. G/Ç bağlantılı bir programın (ağ bağlantıları, dosya işlemleri veya veritabanı işlemleri) çok sayıda iş parçacığıyla daha hızlı gitmesi olası değildir.

Paylaşılan nesne güncelleme sorununu göstermek istiyorsanız, bu basit. Bir grup kağıt kartıyla masaya oturun. 4 veya 6 basit formül içeren basit bir hesaplama kümesini, sayfada çok fazla yer olacak şekilde yazın.

İşte oyun. Her biriniz bir formül okudunuz, bir cevap yazıyorsunuz ve yanıtı bir kart bırakıyorsunuz.

Her biriniz işin yarısını yapacaksınız, değil mi? Yarým zamanda bitirdin deđil mi?

Patronunuz fazla düşünmez ve yeni başlarsa, bir şekilde çatışmaya girersiniz ve her ikisi de aynı formüle cevaplar yazar. Bu işe yaramadı çünkü yazmadan önce ikiniz arasında okuduğunuz doğal bir yarış koşulu var. Hiçbir şey sizi aynı formülü okumanıza ve birbirinizin cevaplarının üzerine yazmanıza engel olmaz.

Kötü veya kilitli olmayan kaynaklarla yarış koşulları oluşturmanın birçok, birçok yolu vardır.

Tüm çakışmalardan kaçınmak istiyorsanız, kağıdı bir formül yığını halinde kesin. Kuyruktan bir tane çıkarırsınız, yanıtı not edersiniz ve cevapları gönderirsiniz. Her ikiniz de tek okuyucu içeren bir mesaj kuyruğundan okuduğunuz için çakışma olmaz.

79
S.Lott

Çok iş parçacıklı programlama, eşzamanlılık için muhtemelen en zor çözümdür. Temelde, makinenin gerçekte ne yaptığının oldukça düşük bir soyutlamasıdır.

aktör modeli veya (yazılım) işlemsel bellek gibi çok daha kolay bir dizi yaklaşım vardır. Veya değişmez veri yapıları (listeler ve ağaçlar gibi) ile çalışmak.

Genel olarak, endişelerin doğru bir şekilde ayrılması çoklu iş parçacığı oluşturmayı kolaylaştırır. Bir şey, çoğu zaman unutulan, insanlar 20 iş parçacığı ürettiğinde, hepsi aynı tamponu işlemeye çalışıyor. Senkronizasyona ihtiyaç duyduğunuz yerlerde reaktörler kullanın ve genellikle farklı mesaj kuyruğu olan çalışanlar arasında veri aktarın.
Uygulama mantığınızda bir kilit varsa, yanlış bir şey yaptınız.

Yani evet, teknik olarak, çok iş parçacıklı işlem yapmak zor.
"Üzerinde bir kilit tokat" eşzamanlılık sorunları için hemen hemen en az ölçeklenebilir çözümdür ve aslında çok iş parçacığının tüm amacı yendi. Yaptığı şey, problemi eşzamanlı olmayan bir yürütme modeline geri döndürmektir. Ne kadar çok yaparsanız, o anda çalışan tek bir iş parçacığına (veya bir kilitlenmede 0) sahip olmanız daha olasıdır. Tüm amacı yendi.
Bu "3. dünyanın problemlerini çözmek kolaydır. Sadece üzerine bomba atın." Önemsiz bir çözüm olduğu için, sonucun kalitesini önemsediğiniz için bu sorun önemsiz değildir.

Ancak pratikte, bu problemleri çözmek diğer programlama problemleri kadar zordur ve en iyi uygun soyutlamalarla yapılır. Bu aslında oldukça kolay.

25
back2dos

Bence bu sorunun teknik olmayan bir açısı var - IMO bu bir güven meselesi. Genellikle örneğin ah, bilmiyorum - Facebook gibi karmaşık uygulamaları yeniden üretmemiz istenir. Sonuç olarak, bir görevin karmaşıklığını açıklanamayan/yönetime açıklamak zorunda kalırsanız - o zaman Danimarka'da bir şeyler çürümüş demektir.

Diğer ninja programcıları 5 dakika içinde bu görevi yerine getirebilse bile, tahminleriniz kişisel yeteneğinize dayanmaktadır. Muhatabınız ya konu hakkındaki fikrinize güvenmeyi öğrenmeli ya da sözünü kabul etmeye istekli birini işe almalıdır.

Buradaki zorluk, insanların ya görmezden gelme ya da konuşma yoluyla kavrayamadığı teknik çıkarımları aktarmak değil, karşılıklı saygı ilişkisi kurmaktır.

14
sunwukung

Kilitlenmeleri anlamak için basit bir düşünce deneyi " yemek felsefecisi " sorunudur. Yarış koşullarının ne kadar kötü olabileceğini tanımlamak için kullandığım örneklerden biri Therac 25 durumudur.

“Sadece bir kilidi tokatlamak”, çok iş parçacıklı zor hatalarla karşılaşmayan birinin zihniyeti. Ve o durumun ciddiyetini abarttığınızı düşünüyor olabilir (yapmıyorum - bir şeyleri patlatmak veya insanları öldürmek mümkündür yarış durumu hataları, özellikle araçlarda bulunan gömülü yazılım ile).

6
Tangurena

İki kelimeyle kısa cevap: GÖZLEMLENEBİLİR NONDETERMİNİZM

Uzun cevap: Sorununuz göz önüne alındığında, eş zamanlı programlamaya hangi yaklaşımı kullandığınıza bağlıdır. Bilgisayar Programlama Kavramları, Teknikleri ve Modelleri kitabında yazarlar, eşzamanlı program yazma konusunda dört ana pratik yaklaşımı açık bir şekilde açıklamaktadır:

  • Sıralı programlama : eşzamanlılığı olmayan bir temel yaklaşım;
  • Deklaratif eşzamanlılık : gözlemlenebilir bir belirsizlik olmadığında kullanılabilir;
  • İleti geçirme eşzamanlılığı : her bir varlığın iletiyi dahili olarak sırayla işlediği birçok varlık arasında geçen eşzamanlı ileti;
  • Paylaşılan durum eşzamanlılığı : paylaşılan pasif nesneleri kaba taneli atomik eylemlerle güncelleme iş parçacığı, ör. kilitler, monitörler ve işlemler;

Açıkça sıralı programlama dışında bu dört yaklaşımın en kolayı bildirici eşzamanlılıktır , çünkü bu yaklaşımı kullanarak yazılan programların gözlemlenebilir belirsizliği yok . Diğer bir deyişle, hiçbir yarış koşulu yoktur , çünkü yarış koşulu sadece gözlemlenebilir belirsiz bir davranıştır.

Ancak gözlemlenebilir belirsizliğin olmaması, bazı problemler olduğu anlamına gelir deklaratif eşzamanlılık kullanarak baş edemeyiz. İşte son iki kolay yaklaşımın devreye girdiği yer burası. O kadar kolay olmayan kısım, gözlemlenebilir belirsizliğin bir sonucudur. Şimdi ikisi de durumsal eşzamanlı model altındadır ve aynı zamanda ifadede eşdeğerdir. Ancak CPU başına giderek artan çekirdek sayısı nedeniyle, endüstrinin son zamanlarda mesaj geçişi eşzamanlılığına daha fazla ilgi gösterdiği görülüyor, mesaj geçiş kütüphanelerinin yükselişinde görüldüğü gibi (örn. Akka JVM için) veya programlama dilleri (örn. Erlang ).

Teorik bir Aktör modeli tarafından desteklenen daha önce bahsedilen Akka kütüphanesi, kilitler, monitörler veya işlemlerle daha fazla uğraşmanıza gerek olmadığından, eşzamanlı uygulamalar oluşturmayı basitleştirir. Öte yandan, çözüm tasarlamak için farklı bir yaklaşım gerektirir, yani aktörleri hiyerarşik olarak nasıl birleştireceklerini düşünmek. Tamamen farklı bir zihniyet gerektirdiğini söyleyebiliriz, ki bu da sonunda düz durum paylaşılan eşzamanlılığını kullanmaktan daha da zor olabilir.

Eşzamanlı programlama gözlemlenebilir belirsizliği nedeniyle zordur , ancak verilen sorun için doğru yaklaşımı ve bu yaklaşımı destekleyen doğru kütüphaneyi kullanırken, sorunları önlenebilir.

3
Jernej Jerin

Eşzamanlı uygulamalar deterministik değildir. Programcının savunmasız olarak kabul ettiği son derece az miktarda genel kodla, bir iş parçacığının/işlemin bir parçasının başka bir iş parçacığının herhangi bir parçasına göre yürütüldüğünü denetlemezsiniz. Test yapmak daha zordur, daha uzun sürer ve eşzamanlılıkla ilgili tüm hataları bulması pek olası değildir. Kusurlar bulunursa, süptil olarak tutarlı bir şekilde çoğaltılamaz, bu nedenle sabitlemek zordur.

Bu nedenle, tek doğru eşzamanlı uygulama, doğru bir şekilde doğru olan, yazılım geliştirmede sıklıkla uygulanmayan bir uygulamadır. Sonuç olarak, S.Lot'un cevabı, mesaj geçişinin doğru olduğunu kanıtlamak nispeten kolay olduğu için en iyi genel tavsiyedir.

3
mattnz

İlk olarak, 2 iş parçacığını başlatan ve her ikisini de aynı anda 1-100 arasında konsola yazdırmasını sağlayan basit bir program görerek sorunları ortaya çıkarabileceği öğretildi. Onun yerine:

1
1
2
2
3
3
...

Bunun gibi bir şey elde edersiniz:

1
2
1
3
2
3
...

Tekrar çalıştırın ve tamamen farklı sonuçlar elde edebilirsiniz.

Birçoğumuz, kodumuzun sırayla çalışacağını varsaymak için eğitildik. Çoğu çoklu iş parçacığında, bunu "kutudan çıkarılmış" olarak kabul edemeyiz.

0