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

Yeni yorum
 
Sevgili forum kullanıcıları.

Birden çok iş parçacığı ile çalışmak için önce eşzamansız, çok iş parçacıklı ve çok işlemcili yürütme arasındaki temel farkı öğrenin, aksi takdirde mantığınızı bazı yerlerde anlamak bile mümkün değildir. Bu zaman.

İkinci olarak, harici DLL'ye yapılan çağrı hala devam ediyor ve birçok iş parçacığı içeren ve onu içeren kendi kitaplığınızı uygulamanızı kim engelliyor?

Üçüncüsü, hangi görevler için mql multithreading'e ihtiyacınız var?

Eh, hala senkronizasyon nesneleri üzerinde çalışmak zorunda olduğunuz gerçeğinden bahsetmiyorum. Ona ihtiyacın var mı? Gerekirse, bir dll yazmak sizin için çok basit bir iştir.
 
Roman :

Yani DLL_PROCESS_ATTACH içinde başlatmak için: programı mql'den çağırmak yeterli olacak mı?

Mql programından, dll'de bulunan işlevlerini çağırın.

 
Dmitry Fedoseev :

Mql programından, dll'de bulunan işlevlerini çağırın.

Ve imzalarını tanımlamanın sorunu nedir? Bir şekilde winapi'yi yöntem imzalarından mı çekiyorsun?
 
Andrey Pogoreltsev :
Ve imzalarını açıklamanın sorunu ne? Bir şekilde winapi'yi yöntem imzalarından mı çekiyorsun?

Ve afedersiniz, neden onları tarif ediyorsunuz? Ve üzgünüm, hiçbir şey çekmedim))

 
Dmitry Fedoseev :

Ve pardon, neden onları tarif ettin? Ve üzgünüm, hiçbir şey çekmedim))

Sori, zaten sorduğunu sanıyordum.
 
Andrey Pogoreltsev :
Sevgili forum kullanıcıları.

Birden çok iş parçacığı ile çalışmak için önce eşzamansız, çok iş parçacıklı ve çok işlemcili yürütme arasındaki temel farkı öğrenin, aksi takdirde mantığınızı bazı yerlerde anlamak bile mümkün değildir. Bu zaman.

İkinci olarak, harici DLL'ye yapılan çağrı hala devam ediyor ve birçok iş parçacığı içeren ve onu içeren kendi kitaplığınızı uygulamanızı kim engelliyor?

Üçüncüsü, hangi görevler için mql multithreading'e ihtiyacınız var?

Eh, hala senkronizasyon nesneleri üzerinde çalışmak zorunda olduğunuz gerçeğinden bahsetmiyorum. Ona ihtiyacın var mı? Gerekirse, bir dll yazmak sizin için çok basit bir iştir.

Andrey, asenkronluk ve çoklu kullanım farklı şeyler, sanırım herkes bunu anlıyor.
CreateThread() işlevi WinAPI Includer'da açıklandığı için, iş parçacıklarının kullanılabileceği varsayılmıştır.
Dahil etmede CreateTask () gibi tanımlanmış işlevler yoktur, o zaman olası bir asenkron kod yazıldığını varsaymak imkansızdır, bir şekilde kendi kendine kaybolur.
Bu nedenle, odak akışlar üzerindeydi. Ancak ortaya çıktığı gibi, açıklanan işlevler yalnızca WinAPI prototipleridir.
Tekrar ediyorum, görev saf WinAPI kullanmaktı ve açıklanan CreateThread() prototipi yanıltıcıydı. Ne de olsa hiçbir yerde bunların prototip olduğu söylenemez.
Herkesin farklı görevleri var, bu yüzden asenkronize oldum ve genel olarak her zaman asenkron veya threadler halinde yazmanın daha iyi olduğunu düşünüyorum.
ve her zaman asenkron yazma alışkanlığını geliştirmek, hızlı programlar yazmanıza ve bir uzman olarak seviyenizi yükseltmenize olanak sağlayacaktır.
Bu, geliştiricilerin kendilerinin ana ilkesidir, mql programlarının yürütme hızı, bu bizim her şeyimiz!

Mql'de böyle bir olasılığın olmaması üzücü,
bu nedenle, asenkron programlama için standart mql işlevleri geliştirmek için yönetime bir teklif yapıyorum ,
akışlarda zaman sorunları ve her şeyden önce güvenlik vardır.
Eşzamansız mod için güvenlik engeli olmadığını düşünüyorum.

yaklaşık mantık

EventLoop uygulamasını mql'de çalışın
MqlTask sınıfı oluştur
görevleri MqlTask obj nesnesi olarak bildirin;
görevler oluştur görev = obj.CreateTask(MyFunc());
başarıyı başlat = görev -> Çalıştır();
 yürütme başarısını askıya al = görev -> SleepMs(ms);
başarıyı beklemek = görev -> Bekle(ms);
süresiz olarak beklemek başarı = görev -> Bekle (0);
silme görevini yürüttükten sonra görevi silin;

peki, kontrol için her türlü getStatus s

 
Roman :

Andrey, asenkronluk ve çoklu kullanım farklı şeyler, sanırım herkes bunu anlıyor.
CreateThread() işlevi WinAPI Includer'da açıklandığı için, iş parçacıklarının kullanılabileceği varsayılmıştır.
Dahil etmede CreateTask () gibi tanımlanmış işlevler yoktur, o zaman kendi kendine kaybolacağı için olası bir asenkron kod yazımı varsaymak imkansızdır.
Bu nedenle, odak akışlar üzerindeydi. Ancak ortaya çıktığı gibi, açıklanan işlevler yalnızca WinAPI prototipleridir.
Tekrar ediyorum, görev saf WinAPI kullanmaktı ve açıklanan CreateThread() prototipi yanıltıcıydı. Ne de olsa hiçbir yerde bunların prototip olduğu söylenemez.
Herkesin farklı görevleri var, bu yüzden asenkronize oldum ve genel olarak her zaman asenkron veya threadler halinde yazmanın daha iyi olduğunu düşünüyorum.
ve her zaman asenkron yazma alışkanlığını geliştirmek, hızlı programlar yazmanıza ve bir uzman olarak seviyenizi yükseltmenize olanak sağlayacaktır.
Bu, geliştiricilerin kendilerinin ana ilkesidir, mql programlarının yürütme hızı, bu bizim her şeyimiz!
Mql'nin böyle bir fırsatı olmaması üzücü, bu nedenle yönetime standart mql işlevleri geliştirmesi için bir teklif yapıyorum.
asenkron programlama için, çünkü iş parçacıkları ve her şeyden önce güvenlikle ilgili sorunlar var.
Eşzamansız mod için güvenlik engeli olmadığını düşünüyorum.
Döngü döngülerinin uygulanması üzerinde çalışın ve bu döngülerdeki görevleri yürütün.

Yöntemleri yürütmek istediğinize eşzamansız veya çok iş parçacıklı olarak zaten karar verdiniz. Soketlerle çalışıyorum, örneğin mql'den eşzamansız olarak.

Bunların imza olduğu hemen ortaya çıktı, güvenli bir sanal yürütme ortamında ne tür dahili uygulamalardan bahsediyoruz? Ve bunu nasıl hayal ediyorsun?

Bir kez daha. Threadlerle çalışmayı bilenler bunun için rahatlıkla DLL yazacak ve tüm görevleri orada yapacaktır.

Ve evet, yanılmıyorsam, mql aynı siparişleri oluşturmak ve ağ ile çalışmak için eşzamansız yöntemlere sahiptir. Asenkron yapmak için hala hangi yöntemlere ihtiyacınız var? Ve tüm bunların pratikliği nedir?

İlgi için, bir iş parçacığında yeterli çalışma hızının olmadığı durumları verebilir misiniz?
 
Andrey Pogoreltsev :
Yöntemleri yürütmek istediğinize eşzamansız veya çok iş parçacıklı olarak zaten karar verdiniz. Soketlerle çalışıyorum, örneğin mql'den eşzamansız olarak.

Bunların imza olduğu hemen ortaya çıktı, güvenli bir sanal yürütme ortamında ne tür dahili uygulamalardan bahsediyoruz? Ve bunu nasıl hayal ediyorsun?

Bir kez daha. Threadlerle çalışmayı bilenler bunun için rahatlıkla DLL yazacak ve tüm görevleri orada yapacaktır.

Ve evet, yanılmıyorsam, mql aynı siparişleri oluşturmak ve ağ ile çalışmak için eşzamansız yöntemlere sahiptir. Asenkron yapmak için hala hangi yöntemlere ihtiyacınız var? Ve tüm bunların pratikliği nedir?

İlgi için, bir iş parçacığında yeterli çalışma hızının olmadığı durumları verebilir misiniz?

Karar vermek için öncelikle mql'de nelerin kullanılabileceğini ve nelerin yasak olduğunu anlamanız gerekir.
Dahil edilenlerde CreateThread() bulundu, bu yüzden threadlerle çalışmanın mümkün olduğunu düşündüm.
Ancak ortaya çıktığı gibi, iş parçacıkları yasaktır, o zaman seçim eşzamansızlığa düşer, ancak mql'den eşzamansızlığın nasıl kullanılacağı da açık değildir.
Evet, sadece soketlerle ilgili bir sorun. Yardım, örneğin ABD hisse senetlerinde bilgi alımını sınırlayan 128'den fazla yuva oluşturamayacağınızı söylüyor.
Ve bu 128 soket bile, gelen verilerin işlenmesinde gecikme olmaması için onları asenkron moda nasıl aktaracakları net değil.
Bu nedenle soruna farklı bir şekilde çözüm aramak zorunda kaldım ama kendi kendine yazılan dll'ler olmadan saf WinAPI üzerinde çözmek istedim .
Ama mql'de asenkron olarak nasıl çalışılır zaten ilginç, çalışan örnekler varsa bilgi paylaşırsanız bunları tartışmak fena olmaz.
Ancak mql yardımında herhangi bir standart eşzamansız yöntem görmüyorum.

 
Roman :

Karar vermek için öncelikle mql'de nelerin kullanılabileceğini ve nelerin yasak olduğunu anlamanız gerekir.
Dahil edilenlerde CreateThread() bulundu, bu yüzden threadlerle çalışmanın mümkün olduğunu düşündüm.
Ancak ortaya çıktığı gibi, iş parçacıkları yasaktır, o zaman seçim eşzamansızlığa düşer, ancak mql'den eşzamansızlığın nasıl kullanılacağı da açık değildir.
Evet, sadece soketlerle ilgili bir sorun. Yardım, örneğin ABD hisse senetlerinde bilgi alımını sınırlayan 128'den fazla yuva oluşturamayacağınızı söylüyor.
Ve bu 128 soket bile, gelen verilerin işlenmesinde gecikme olmaması için onları asenkron moda nasıl aktaracakları net değil.
Bu nedenle soruna farklı bir şekilde çözüm aramak zorunda kaldım ama kendi kendine yazılan dll'ler olmadan saf WinAPI üzerinde çözmek istedim .
Ama mql'de asenkron olarak nasıl çalışılır zaten ilginç, çalışan örnekler varsa bilgi paylaşırsanız bunları tartışmak fena olmaz.
Ancak mql yardımında herhangi bir standart eşzamansız yöntem görmüyorum.

Winapi üzerinden soketlerle asenkron çalışmak istiyorsanız, winsock2 kullanın.

OVERLAPPED ve WSAEVENT ile WSARecv ve WSASend'i deneyin .

Sonra Bekleyin...
 

Akıllı katılımcıları okuyorum ve kafam karıştı ...

Ve neden tüm bu çanlar ve ıslıklar?

MQL'de çok iş parçacığının ne zaman çok gerekli olacağı konusunda bir örnek verebilir misiniz? Benim için tek uygulama, oldukça normal olarak düzenli yollarla uygulanan test stratejileridir.

Teorik olarak, birkaç WebRequest'i çalıştırmak mantıklı olabilir, ancak bence çoklu kullanım hiç gerekli değildir.

Hangi görevler doğrudan çoklu kullanım gerektirir?

1234567891011...40
Yeni yorum
Neden: