Printable View
BTW: apakah Anda sudah melihat utas saya tentang membuat dll dengan FPCLazarus?
https://www.forexfabrikasi.com/gener...oning-egy.htmlSaya harus menambahkan bab yang membahas variabel global, cara menghindarinya dan bagaimana menggunakannya jika benar-benar diperlukan.
Sebagai aturan, vars Global di DLL Anda akan dibuat saat DLL dimuat (panggilan pertama ke DLL). dan diubah oleh SEMUA akses. Variabel lokal dalam setiap fungsi di-alo ketika fungsi dipanggil dan pointer ke mereka disimpan di stack, mereka hanya diakses oleh pemanggilan fungsi yang membuatnya, dan mereka dihancurkan ketika fungsi keluar. Masalah yang Anda miliki adalah masalah Multi Threading EG: - E1 dan E2 masing-masing 2 EA berjalan di utas yang berbeda. D1 DLL Anda F1, fungsi DLL Anda, Kode yang Dimasukkan/Kode DLL Anda/Global Var int x; membatalkan F1 (); {int y;/var lokal x = 1000; while (xgt; 0) {y = 2000; while (ygt; 0) {y--;} x--; }} Jadi ketika dijalankan, hal berikut dapat dan akan terjadi: E1 memanggil F1, dan 'temp' var Y baru dibuat. Itu kemudian berhenti berjalan di tengah fungsi karena OS mengatakan kutu waktu sudah habis. Semuanya bekerja dengan baik. Jika E2 tidak ada tidak akan ada masalah sama sekali. E2 sekarang memanggil F1 dan 'temp' var Y baru dibuat. F1 Segera mengeset x ke 1000 ... Sekarang Anda telah memecah panggilan E1 ke fungsi karena variabel global telah berubah, dan ketika E1 mendapatkan prosesor kembali, itu akan menemukan int x berbeda dari ketika itu ditinggalkan. Tentu saja E1 tidak akan tahu, atau peduli tentang ini. Anda dapat dengan mudah menyelesaikan ini tanpa OOP Anda hanya perlu menyadari bahwa Anda memanggil fungsi yang sama dari beberapa utas sehingga Anda harus aman utasnya. Baik dengan atau tanpa OOP Anda harus memiliki cara untuk mengubah int X yang terpisah untuk setiap EA. Karenanya, kebutuhan untuk menyediakan fungsi Init untuk membuat 'bank' variabel global yang terpisah untuk setiap EA. Dalam contoh di atas ini dapat dengan mudah dicapai dengan membuat Int X array ukuran yang sesuai, dan menyediakan fungsi initdeinit untuk menambahkan elemen dimensi array ke setiap pemanggil unik ke fungsi init. MISALNYA. E1 int myID = DLLinit ('GBPJPY');/mengembalikan 1 F1 (myID);/sekarang F1 dapat menggunakan MyID untuk referensi X var yang benar dalam array global. E2 int myID = DLLinit ('EURUSD');/mengembalikan 1 OOP seringkali merupakan cara yang jauh lebih elegan untuk menyapu masalah ini tetapi hanya akan berfungsi jika Anda memahami masalahnya dan kemudian mengkodekannya dengan benar. Dengan OOP Anda akan mencari untuk membuat objek baru (satu untuk setiap EA) ketika mereka memanggil fungsi init DLL. Ini hanya akan berfungsi jika Anda merangkum sekumpulan variabel 'Global' terpisah dalam setiap objek baru.
7bit: saya telah mengubah kode untuk tidak memiliki beberapa variabel global, saya bahkan belum menyadarinya sampai saya menempelkan kode, juga dengan konfirmasi Anda bahwa mereka bertahan di antara panggilan masuk akal mengapa itu melakukan apa itu . saya akan memberi tahu Anda bagaimana saya melanjutkan dengan pengujian demo itu. saya akan melihat artikel Anda sekarang, saya mungkin telah membacanya, Anda banyak membaca hari ini! sekali lagi terima kasih
Rangebound: Terima kasih atas posting Anda, saya dapat melihat masalah yang saya salah adalah bahwa saya menganggap bahwa setiap beban EA akan memuat instance DLL yang terpisah, terpisah dengan baik dari panggilan lain yang mungkin sedang terjadi. Sepenuhnya setuju dengan contoh Anda. Lucunya mengetahui bahwa ini sebenarnya telah memberi saya solusi untuk masalah lain yang saya miliki, jawabannya ada di sana selama ini. Terima kasih atas bantuan Anda
Saya juga ingin mengucapkan terima kasih! ke 7bit dan rangebound untuk bantuan mereka di sini. Sudah sangat membantu. Saya menggunakan Delphi 2009 (Object Pascal) untuk menulis DLL saya. Menggunakan saran di utas ini dan juga yang ini, saya telah menghilangkan semua crash dengan memindahkan semua variabel global ke kelas dan melewatkan sebuah pointer ke objek antara MT4 dan DLL. Ini menyelesaikan setiap tabrakan memori. Namun, sepertinya masih ada sesuatu yang aku tidak mengerti. Untuk menghindari SEMUA macet, saya perlu menggunakan TCriticalSection untuk memastikan bahwa hanya satu bagan yang mengakses DLL pada suatu waktu. Sebagai contoh: Dimasukkan Kode/Delphi (Obyek Pascal) Kode DLL: var csTick: TCriticalSection; fungsi DLLGet: Boolean; mulai csTick. Masukkan; Hasil: = Benar; akhir; prosedur DLLFree; mulai csTick.Leave; akhir; inisialisasi csTick: = TCriticalSection.Create; finalisasi csTick.Free; Kode yang dimasukkan/Kode EA: #import MyLogic.dll bool DLLGet (); membatalkan DLLFree (); #import int init () {DLLGet (); int iPointer = DLLGetNewObject (Symbol ()); ... Inisialisasi lainnya ... DLLFree (); return (0); } int start () {static int iPrevOrderCount = 0; DLLGet (); ... beberapa panggilan fungsi DLL ... DLLFree (); return (0); } Sekali lagi, saya tidak punya vars global di DLL; semuanya (kecuali objek TCriticalSection) dibungkus dalam kelas, dan referensi kelas diteruskan ke DLL dengan setiap pemanggilan fungsi. Tapi saya masih mendapatkan semacam tabrakankorupsi karena saya perlu menggunakan semaphore utas (TCriticalSection) untuk membuatnya berfungsi dengan baik. Inilah alasan saya membawa semua ini. Masih ada satu masalah kecil: jika deinit () dipanggil untuk bagan, MT4 langsung keluar dari fungsi start (), yang kadang-kadang berarti DLLFree () tidak dipanggil dan semua grafik lainnya dikunci dari DLL. Jadi dalam ringkasan pertanyaan saya adalah: mengapa saya perlu menggunakan semaphore TCriticalSection? Jika semuanya ada di kelas, tabrakan apa lagi yang bisa terjadi? Terima kasih!
Salahku
https://www.forexfabrikasi.com/attac...1529225859.png. Saya memang menemukan global var di unit yang disertakan. Saya menghapus var itu dan semuanya baik-baik saja sekarang - tanpa perlu semaphore! Sekali lagi, terima kasih atas bantuan Anda.
Anda tidak perlu menggunakan bagian penting untuk sebagian besar DLL sehingga ini menunjuk ke beberapa masalah pengkodean lain yang mendasarinya, yang bisa menjadi salah satu dari banyak hal. Yang terbaik yang bisa Anda lakukan adalah .... Memotong kode DLL Anda sampai Anda memiliki DLL paling dasar yang masih Gangguan. Kemudian kirimkan sumbernya di sini dan saya akan memeriksanya. Mengingat Anda tidak menyatakan ketika terjadi crash ... Jika Anda tidak ingin turun rute itu maka tebakan terbaik saya adalah: 1) Jika EA Anda melakukan deinitInit maka DLL Anda mungkin mencoba membuat objek kedua untuk pasangan mata uang yang sama. Sudahkah Anda membuat kode jebakan untuk menghentikan dupliion. Jangan anggap DLL Anda dijamin untuk mendapat panggilan DeInit. Anda harus memeriksa duplikasi inisialisasi mata uang yang sama. 2) Apakah Anda DLL menyimpan pointer ke, dan mengelola penghancuran Objek ini?
Rangebound terima kasih! Semuanya berfungsi dengan baik sekarang, tanpa kerusakan atau kebocoran memori, tetapi posting Anda menimbulkan beberapa pertanyaan:
Cara saya menulisnya, jika deinit () tidak dipanggil, objek tidak akan dibebaskan. Tetapi selain dari kebocoran memori yang seharusnya tidak menyebabkan crash karena objek kedua akan memiliki memori baru, benar?Quote:
Originally Posted by ;
Biasanya saya akan menggunakan TThreadList (daftar thread-blocking pointer) di DLL untuk melakukan sesuatu seperti ini - apakah ada cara lain? Dengan kata lain, bagaimana saya harus menyimpan pointer di DLL tanpa menggunakan global var atau mekanisme pemblokiran? Ini sangat membantu - terima kasih atas masukan Anda.Quote:
Originally Posted by ;
Quote:
Originally Posted by ;
Yup, itulah tepatnya yang saya lakukan, tetapi RangeBound mengangkat kekhawatiran tentang objek yang tidak dibebaskan karena DeInit () mungkin tidak dipanggil, dan menyarankan saya menyimpan daftar pointer di DLL sehingga dapat mengelola memori.Quote:
Originally Posted by ;