MQL'de asenkron ve çok iş parçacıklı programlama - sayfa 34

Yeni yorum
 
Andrei Novichkov :
Ama burada merak ettiğim başka bir şey var, gerçekten bir iş parçacığı havuzu gerektirecek herhangi bir görev var mı? Sadece - bir iş parçacığı oluşturdum - unuttum ve Williams'ın nasıl tanımladığına göre havuzun bitmesini mi bekliyoruz? Orada bir örnek verilmiş, bir ATM gibi görünüyor, karıştırmıyorsam, ama ülkemizde böyle bir Yudo mucizesi hangi görevi haklı gösterebilir. Henüz böyle bir sorunla karşılaşamadım. Ve sonra neden her şeyin zaten yapıldığı ThreadPool'a gerçekten bakmıyorsunuz, belgeler var, örnekler var.

Dürüst olmak gerekirse, std :: async ile iş parçacığı havuzu arasında henüz pek bir anlam ifade etmedim, bunun dışında std :: async gerçekleştirilen görev için otomatik olarak bir iş parçacığı oluşturur ve yok eder.
Ve iş parçacığı havuzunu kullanmak için, programda kullanılan iş parçacığı sayısını önceden bilmeniz ve bu sayıyı havuz için açıkça ayarlamanız gerekir.
İş parçacığı havuzunun iş parçacığı sayısı açısından statik olduğu ortaya çıkıyor, ancak durum böyle olmasa da söyleyemem.
Ancak kitapta Williams, std::thread'de yürütülecek çok fazla görev olduğunda iş parçacığı havuzunun önerildiğini yazıyor.
Ve belki de bu, anlamını tam olarak anlayana kadar std ::async için geçerli değildir.
Asenkron, ağ çözümlerinde ve çok sembollü stratejilerde çok talep görüyor ve aynı zamanda yüklü hesaplamalar için de kullanışlı.
Ancak standartta std ::async ve std::promise olması, bana öyle geliyor ki bir iş parçacığı havuzu oluşturmaya gerek yok.

 

Yine de dll için projenin kurulumuyla ilgili bir soru vardı.
Derleyiciler tarafından otomatik olarak dll bağımlılığına çekilen kullanılmayan işlevlerden nasıl kurtulur?

Zaten farklı geliştirme ortamları denedim ve her biri kendi kullanılmayan işlevini çekiyor.
MSVS_2017 genellikle, muhtemelen ortadan kaldırılamayan kendi çalışma zamanı bağımlılıklarını çeker.
Bu nedenle, farklı IDE'ler denedim, ancak kullanılmayan işlevleri de çekiyorlar.
Onlardan nasıl kurtulurum?

 
Roman :

Dürüst olmak gerekirse, std :: async ile iş parçacığı havuzu arasında henüz pek bir anlam ifade etmedim, bunun dışında std :: async gerçekleştirilen görev için otomatik olarak bir iş parçacığı oluşturur ve yok eder.
Ve iş parçacığı havuzunu kullanmak için, programda kullanılan iş parçacığı sayısını önceden bilmeniz ve bu sayıyı havuz için açıkça ayarlamanız gerekir.
İş parçacığı havuzunun iş parçacığı sayısı açısından statik olduğu ortaya çıkıyor, ancak durum böyle olmasa da söyleyemem.
Ancak kitapta Williams, std::thread'de yürütülecek çok fazla görev olduğunda iş parçacığı havuzunun önerildiğini yazıyor.
Ve belki de bu, anlamını tam olarak anlayana kadar std ::async için geçerli değildir.
Asenkron, ağ çözümlerinde ve çok sembollü stratejilerde çok talep görüyor ve aynı zamanda yüklü hesaplamalar için de kullanışlı.
Ancak standartta std ::async ve std::promise olması, bana öyle geliyor ki bir iş parçacığı havuzu oluşturmaya gerek yok.

Bu nedenle, async'in ana noktası, bir iş parçacığı havuzu kullanmak, sürekli iş parçacığı oluşturma/silme ile ilişkili ek yüklerden kurtulmaktır, eğer zaman uyumsuz bunu yapmazsa, o zaman değersizdir.

Genel olarak, görünüşe göre async hakkında çok kötü düşündüm. Basit bir test, onu tamamen yeterli bir şey olarak gösterir:

 #include <future>
#include <iostream>
#include <vector>
using namespace std;

int main()
{
    cout << "Main thread id: " << this_thread::get_id() << endl;
     for ( int i = 0 ;  i < 2 ;  ++ i){
       cout << "------------------------" << endl;
       vector<future< void >> futures;
       for ( int i = 0 ; i < 10 ; ++i)
       {
          this_thread::sleep_for( 1 ms);
          auto fut = async([]{
                              this_thread::sleep_for( 1 s);
                              cout << this_thread::get_id() << '\n' ;
                           });
          futures.push_back(move(fut));
       }
       for (auto &f : futures)
          f.wait();
    }

    cout << endl;
}

Main thread id: 140657228855104

140657228850944
140657220458240
140657212065536
140657203672832
140657195280128
140657186887424
140657178494720
140657170102016
140657161709312
140657153316608
------------------------
140657153316608
140657161709312
140657170102016
140657178494720
140657228850944
140657220458240
140657212065536
140657203672832
140657195280128
140657186887424

İkinci görev grubu için, daha önce oluşturulmuş iş parçacıklarının zaman uyumsuz olarak kullanılmasının yenilerini oluşturmadığı görülebilir. Bu yüzden muhtemelen pek hak etmediğim şekilde suladım.

 
Roman :

Yine de dll için projenin kurulumuyla ilgili bir soru vardı.
Derleyiciler tarafından otomatik olarak dll bağımlılığına çekilen kullanılmayan işlevlerden nasıl kurtulur?

Mingw için, -static seçeneği statik ile yardımcı olmalıdır , resim oluşturmayı durdurur

 

Daha zor zaman uyumsuz testi

 #include <future>
#include <iostream>
#include <vector>
#include <mutex>
#include <set>
using namespace std;

mutex mtx;
set<thread::id> id;
atomic< unsigned > atm{ 0 };

int main()
{
   for ( int i = 0 ;  i < 10000 ;  ++ i) {
      vector<future< void >> futures;
       for ( int i = 0 ; i < 10 ; ++i) {
         auto fut = async(launch::async,[]{
                                           ++ atm;
                                           lock_guard<mutex> lck{mtx};
                                           id.insert( this_thread::get_id() );
                                        });
         futures.push_back(move(fut));
      }
   }

   cout << "executed " << atm << " tasks, by " << id.size() << " threads\n" ;
}
// cout: executed 100000 tasks, by 10 threads

Eh, genel olarak, evet, iyi çalışıyor. Neden onun hakkında bu kadar kötü düşünüyordum? Muhtemelen c++ 11'in şafağında çarpık uygulamalar ...

Not: ancak lanch::async ilkesiyle çok yavaş async()'in, lanch::deferred ile değiştirirseniz (+ ilk döngünün sonunda görevlerin tamamlanmasını bekleyin), o zaman bu basit test başlar 30 kat daha hızlı çalışmak için !!! Bu çok iş parçacıklı)). Bu nedenle, kendi kendine yapılan bir iş parçacığı havuzu için yer var, bana göre standart olandan çok daha hızlı yapabilirsiniz.

 
Roman :

Yine de dll için projenin kurulumuyla ilgili bir soru vardı.
Derleyiciler tarafından otomatik olarak dll bağımlılığına çekilen kullanılmayan işlevlerden nasıl kurtulur?

Zaten farklı geliştirme ortamları denedim ve her biri kendi kullanılmayan işlevini çekiyor.
MSVS_2017 genellikle, muhtemelen ortadan kaldırılamayan kendi çalışma zamanı bağımlılıklarını çeker.

Kabul edin ve unutun veya puan verin.
Nasıl ve neden engelliyor? Saçmalıkları komşulara bırakın.)
Üst düzey diller, programcının ayrıntılarla ilgilenmemesi için tasarlanmıştır. Bu kraliyet işi değil. Evet ve neyin gerekli olduğunu, neyin gerekli olmadığını nereden biliyorsunuz? Derleyici daha iyi bilir.
 
Vict :

Daha zor zaman uyumsuz testi

Eh, genel olarak, evet, iyi çalışıyor. Neden onun hakkında bu kadar kötü düşünüyordum? Muhtemelen c++ 11'in şafağında çarpık uygulamalar ...

Not: ancak lanch::async ilkesiyle çok yavaş async()'in, lanch::deferred ile değiştirirseniz (+ ilk döngünün sonunda görevlerin tamamlanmasını bekleyin), o zaman bu basit test başlar 30 kat daha hızlı çalışmak için !!! Bu çok iş parçacıklı)). Bu nedenle, kendi kendine yapılan bir iş parçacığı havuzu için yer var, bana göre standart olandan çok daha hızlı yapabilirsiniz.

Sonuna kadar okumadım ve ertelenmiş bayrakla çalıştırmanızı önermeye karar verdim)))))) Böyle bir test daha hızlıysa, genellikle bu şekilde kullanmanın tercih edildiğini düşünüyorum, neden katı ayarlasın? sınırlar. Git'e olan bağlantınız için teşekkür etmek istedim, ilgiyle baktım)) İki seçeneğin olduğunu gerçekten beğendim - takviyeli ve desteksiz.

Roma :

Yine de dll için projenin kurulumuyla ilgili bir soru vardı.
Derleyiciler tarafından otomatik olarak dll bağımlılığına çekilen kullanılmayan işlevlerden nasıl kurtulur?

Zaten farklı geliştirme ortamları denedim ve her biri kendi kullanılmayan işlevini çekiyor.
MSVS_2017 genellikle, muhtemelen ortadan kaldırılamayan kendi çalışma zamanı bağımlılıklarını çeker.
Bu nedenle, farklı IDE'ler denedim, ancak kullanılmayan işlevleri de çekiyorlar.
Onlardan nasıl kurtulurum?

Ve çalışma zamanı olmadan nasıl? Ve evet, her yerde farklıdır. Hayır, çalışma zamanı olmadan dürtme veya çekme yok)))) Henüz QT ile çalışmadınız, DLL'den gelen bütün bir sosis çelengi burada uzanıyor.


 
Andrei Novichkov :

Sonuna kadar okumadım ve ertelenmiş bayrakla çalıştırmanızı önermeye karar verdim))))



Ertelenmiş bayrakla neden async()'e ihtiyacımız var? Gerçekten anlamıyorum, açıklayabilir misin?

 
Vict :

Ertelenmiş bayrakla neden async()'e ihtiyacımız var? Gerçekten anlamıyorum, açıklayabilir misin?

Ve aslında neden belgelerdeki bayrak hakkında bir şey okumuyorsunuz? https://en.cppreference.com adresinde. Ve stackoverflow.com'da tartışılan örnekler. Genelde size tavsiye ettiğim bu bilgi kaynaklarını kullanırım.

 
Andrei Novichkov :

Ve aslında neden belgelerdeki bayrak hakkında bir şey okumuyorsunuz? https://en.cppreference.com adresinde. Ve stackoverflow.com'da tartışılan örnekler. Genelde size tavsiye ettiğim bu bilgi kaynaklarını kullanırım.

MSDN. Eksiksiz belgeler. Gerisi sadece ekstra. malzeme.
1...2728293031323334353637383940
Yeni yorum