multithreadingi anlayamıyorum c++

[Artariel]

paylaşılan değişkenler aynı anda erişildiğinde mutex locka sebep oluyor tamam. bu yüzden de critical section tarzı şeyler oluşturuluyor tamam.

ama hangi değişkeni ne zaman bu sectiona sokmalıyım ? yani section bildiğim kadarıyla aynı anda yapılacak iki işlemi sıraya sokuyor, e benim ortak kullanmak zorunda olduğum değişkeni sürekli sectionda tutmak zorunda kalacaksam neden multithreading yapayım ? yine sıraya göre gerçekleşecek çünkü yapacağım şey.

yani bir şeyleri threadsafe yapmak için aslında multithreadingden çıkmış olmuyor muyuz ?

biri bana bunu açıklamalı. neden, ne zaman multithreading ve critical sectionu kullanmalıyım. ne zaman tam anlamıyla işimi görebilir ? nedir bu multithread

[SpiderS_DangeR]

Abi eğer threadlerin tek işi shared variable'ı alıp üzerinde işlem yapıp geri yazmak ise multithreading bir işe yaramıyor tabi ama threadler birbirinden bağımsız işler yapıp arada bir de shared variable'ı kullanmaları gerekiyorsa o zaman daha efektif tabi multithreading.

[reyou]

yapilacak islerin sirasi onemli degilse, yani sequential bi sirada zorunlulugu yoksa her daim multithreading kullanabilirsin.

[reyou]

oteki turlu round robin gogogo

[Eralpb]

Mutex lock öyle neden olunacak bir şey değil ki; sen mutex lock yaparsın unlock edene kadar olan kodlar da "critical section" olmuş olur.

Tabii kodunda critical section oranı ne kadar fazlaysa multi-threading yapmak o kadar daha az performans getirecektir.

Diyelim yemek yeme işi bir thread yemekhanede de 100 kişi yemek yiyor aynı anda. Bu 100 kişinin ortak kullandığı resource aşçının kepçesi,aynı anda ancak 1 kişiye yemek koyabiliyor. Yani aşçının karşısına geldiğinde aşçının kepçesini lockluyosun ve kendine yemek koyma işlemini yapıyosun sonra release edip kendi işine bakıyorsun.

Senin sorun niye aynı anda yemeğe iniyoruz aşçının kepçesi anca 1 kişiye yemek koyabiliyo, çünkü thread-safe olması gerekmeyen kısım yani asıl yeme kısmı daha çok zaman alıyor.

Nerede locklayıp nerede açacağını tahmin etmek de uygulamaya göre değişir, yemeğini bitirene kadar aşçının kepçesini release etmezsen o multithreadingden hayır gelmez, ama ilk uygulamalarda bunu tahmin etmek o kadar da zor olmaz heralde

[Artariel]

Eralpb said:

Mutex lock öyle neden olunacak bir şey değil ki; sen mutex lock yaparsın unlock edene kadar olan kodlar da "critical section" olmuş olur.

Tabii kodunda critical section oranı ne kadar fazlaysa multi-threading yapmak o kadar daha az performans getirecektir.

Diyelim yemek yeme işi bir thread yemekhanede de 100 kişi yemek yiyor aynı anda. Bu 100 kişinin ortak kullandığı resource aşçının kepçesi,aynı anda ancak 1 kişiye yemek koyabiliyor. Yani aşçının karşısına geldiğinde aşçının kepçesini lockluyosun ve kendine yemek koyma işlemini yapıyosun sonra release edip kendi işine bakıyorsun.

Senin sorun niye aynı anda yemeğe iniyoruz aşçının kepçesi anca 1 kişiye yemek koyabiliyo, çünkü thread-safe olması gerekmeyen kısım yani asıl yeme kısmı daha çok zaman alıyor.

Nerede locklayıp nerede açacağını tahmin etmek de uygulamaya göre değişir, yemeğini bitirene kadar aşçının kepçesini release etmezsen o multithreadingden hayır gelmez, ama ilk uygulamalarda bunu tahmin etmek o kadar da zor olmaz heralde

gayet güzel anlattın peki ortak kullanılan değeri her yerde mi critical'e almalıyım ? yani sırayı os mu ayarlıyor. iki thread de aynı anda critical sectiona girdi mesela.

[SpiderS_DangeR]

Abi olayın OS ile bir ilgisi yok ki, sen ayarlıyorsun shared variableları, lockları vs. 2 thread'in de ortak kullandığı bir variable varsa işte, herhangi bir thread o variable ile bir işlem yapacağı zaman variable'ı kitliyorsun, zaten critical regiona girmiş oluyorsun, sonra işin bitince variable'la kilidi açıyorsun.
Zaten ciritical region'ın olayı o, 2 tane thread aynanda giremiyor.

[Artariel]

sırayı mı os belirliyor anlamında sormuştum. yani aynı anda sectionlara giren threadlerin öncelik sırasını os mu atıyor kafasına göre

bir de mesela soketleri blocking yaptığımı farz ederek udp listen için ayrı, tcp listen için ayrı ve buralardan gelecek dataların işlendiği threadi ayrı yaratırsam, non-blocking soketlere göre daha mı performanslı bi iş yapmış olurum ? yani bunun bana tek maliyeti daha karmaşık bir kod mu olur ?

[SpiderS_DangeR]

Valla single core processorlerde mutex lock işlemi atomic olduğundan dolayı zaten o thread'e interrupt gelemiyor, o yüzden aynanda diye birşey yok. Fakat multicorelarda 2 thread aynanda mutexi 1 yapmaya çalışırsa hangisinin critical regiona girebileceğine kimin neye göre karar verdiğini bilmiyorum. Fakat diyelimki mutex 1 iken 2 farklı thread c.regiona girmeye çalıştı ve kilitli olduğu için giremediler ve ikiside blocking oldu, bu durumda mutex 0landığında hangi thread'in c. regiona gireceğine OS random olarak karar veriyor, senin sorunun cevabı da budur büyük ihtimalle. (Mutexden bahsediyorum bu arada semaphorelarda durum farklı).

2. soruna gelirsek, non-blocking yaparsan threadler busy waiting yapar ve sürekli CPU'dan yer, doğal olarak blocking yaparsan daha performanslı olur. Karmaşık bir koddan kastın da yazması daha zor olan kodsa evet daha karmaşık ama performanslı olur, fakat aslında hiç de karmaşık olmaz yani dsf

[fizban]

Eralpb said:

Diyelim yemek yeme işi bir thread yemekhanede de 100 kişi yemek yiyor aynı anda. Bu 100 kişinin ortak kullandığı resource aşçının kepçesi,aynı anda ancak 1 kişiye yemek koyabiliyor. Yani aşçının karşısına geldiğinde aşçının kepçesini lockluyosun ve kendine yemek koyma işlemini yapıyosun sonra release edip kendi işine bakıyorsun.

Senin sorun niye aynı anda yemeğe iniyoruz aşçının kepçesi anca 1 kişiye yemek koyabiliyo, çünkü thread-safe olması gerekmeyen kısım yani asıl yeme kısmı daha çok zaman alıyor.

Nerede locklayıp nerede açacağını tahmin etmek de uygulamaya göre değişir, yemeğini bitirene kadar aşçının kepçesini release etmezsen o multithreadingden hayır gelmez, ama ilk uygulamalarda bunu tahmin etmek o kadar da zor olmaz heralde

dining philosophers lololo.

[nameless]

paralel çalışma yerine pipeline çalışma yapıyorsun anladığım kadarıyla. bir çok shared değişkene ulaşman gerekiyorsa ve paralel çalışacak bölümler de kısıtlıysa paralelleştirmenin anlamı yok. Kesin bir ifade kullandım ama bir profiler ile izlersen uygulamanı ve gerekli ortamın varsa 1, 2, .., n işlemci/thread'e çıkabileceğin o zaman daha sağlıklı olur kanıya varmak.

[Eralpb]

Düşük client sayısında hangisi daha performanslı bilmiyorum ama thread-per-connection mimarisi scalable değil, select fonksiyonu hayat kurtarıyor.

Mesela dediğin durumda:

	int current = 0;

	char buffer[1024];

	

	void thread1()

	{

	 char buffer2[1024];

	 for(;;){

	  int nbytes = socket.blockingread(buffer2);

	

	  mutex.lock();

	  memcpy(buffer+current,buffer2,nbytes);

	  current += nbytes;

	  mutex.unlock();

	 }

	}

	

	void thread2()

	{

	 char mesaj[1024];

	 for(;;){

	  int len = 0;

	

	  mutex.lock();

	  if(current > 0){

	  memcpy(mesaj,buffer,current);

	  len = current;

	  current = 0;

	  }

	  mutex.unlock();

	  

	  if(len > 0)

	  gelenmesajlaislemyap(mesaj,len);

	

	  //gui update etc.

	 }

	}

	

	void main()

	{

	 int t1,t2;

	 t1 = startThread(thread1);

	 t2 = startThread(thread2);

	 threadJoin(t1);

	 return;

	}

	

burda mesela thread1 blocking read'de beklerken ( ki zamanın 100de 99'unda bekliyor olacak) thread2 mutex.locklar yokmuş gibi çalışacak, yani neredeyse hiçbişey beklemeyecek. thread1 ne zaman mutex lock yaparsa thread2 mutex.lock satırında çok az bekleyecek,ha eğer thread1 mutex lock yapmaya çalıştığında thread2 lock içerisindeyse ordan çıkana kadar thread1 bekleyecek.

Tabi bu kod çok anlamsız oldu çünkü thread2deki şeyleri thread1e de koysak kod aynı çalışır, ama burda avantaj sürekli çalıştırmak istediğimiz bir şey varsa bir hesaplama veya gui update gibi onu oraya koyabiliriz.