October 05, 2013

Alıntı (darkofpain):

>

ama sabit iş parçacığı 15 adet ile sınırlandırmak yerine

Eğer iş parçacığı adedini beklemekte olan istek adedinin bir fonksiyonu olarak tanımlayabiliyorsan kaba hatlarıyla basit bir işlem gibi görünüyor:

size_t gerekenİşçi(size_t bekleyenİstek)
{
   // Senin programınca nasıl bir algoritma olacağını buradan
   // bilemeyiz. Herhalde denemeler yaparak bileceksin. Rasgele bir
   // algoritma:
   return (bekleyenİstek / 10) + 1;
}

void main()
{
   // Burada isteği kuyruğa yerleştir

   // Burada bu hesapları yap
   size_t beklemekteOlanİstekAdedi = 1000;
   size_t mevcutİşçiAdedi = 3;

   if (gerekenİşçi(beklemekteOlanİstekAdedi) < mevcutİşçiAdedi) {
       // Burada yeni işçi başlat
   }

   // Burada boş bir işçiye bekleyen bir isteği ver
}

Alıntı:

>

peki bunu hesaplamak ve istekleri diziye alma işlemini nasıl yapabilirim yardımcı olabilirmisiniz.

Hesaplama yukarıdaki gibi basitçe olabilir.

Diziye alma sorusu diğerinden daha da basit olduğu için ya ben bu soruların karmaşıklığını anlamıyorum ya da sen gereğinden daha karmaşık olduklarını sanıyorsun. :) D'de diziye eleman almaktan kolay ne var? :)

struct İstek
{
   // ...
}
// ...
   İstek[] istekler;
   // ...
   istekler ~= yeniİstek;

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 08, 2013

teşekkür ederim.

öğrendiğim bazı bilgiler neticesinde http işlemlerinde threadlar çok tavsiye edilmez eş zamanlılık (concurrency) tavsiye ediliyor.

google ın dili olan Golang de herşey concurrency üzerine kuruludur o yüzden temiz bir mantık ile tamamen eş zamanlama üzerine yönelmek daha mantıklı ancak thread lar gelen istek icerisinde yapılacak işlemler için kullanılabilir mesala template sınıfı varsa burada parse yaparken kullanılabilir gibi.

Go lang de dahili http sunucu çok büyük projeler üzerinde kullanılabilir bir yapısı var ve tamamen concurrency üzerine kurulur.

burada önemli olan i/o hızlı bir şekilde okuyup çıktı vermesi gerekiyor ve engelleme yapmadan.

http://vimeo.com/49718712 = Rob Pike - 'Concurrency Is Not Parallelism'

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 08, 2013

Alıntı (darkofpain):

>

http işlemlerinde threadlar çok tavsiye edilmez eş zamanlılık (concurrency) tavsiye ediliyor.

Orada bir terim karmaşası var çünkü eş zamanlılık çoğu zaman thread'ler ile sağlanır. Örneğin Phobos'un std.concurrency (ve std.parallelism) modülü perde arkasında thread kullanır.

Alıntı:

>

Golang de herşey concurrency üzerine kuruludur o yüzden temiz bir mantık ile tamamen eş zamanlama üzerine yönelmek daha mantıklı

Eş zamanlılığın Go'nun da kullandığı daha hızlı bir gerçekleştirmesi daha var: Go'nun goroutine, başkalarının coroutine, fiber, greenlet, vs. diye adlandırdıkları kavram.

Daha önce burada geçmiş miydi? Martin Fowler disruptor denen bir mimariyi anlatıyor:

http://martinfowler.com/articles/lmax.html

CPU'nun iş parçacıkları üzerinde sürekli gezinmelerinin getirdiği masraftan kurtulmak için onları yalnızca giriş ve çıkış noktalarında kullanıyorlar. Asıl işi ise tek iş parçacığı hallediyor.

Alıntı:

>

http://vimeo.com/49718712 = Rob Pike - 'Concurrency Is Not Parallelism'

Şu anda o filmi izleyemiyorum ama en azından başlık konusunda içim rahat. :) Parallelism (koşut işlemler) ve concurrency (eş zamanlı programlama) kavramlarının farklı olduklarını kitabın ilgili bölümlerinde önemle belirtiyorum.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

1 2
Next ›   Last »