Errori, bug, domande - pagina 2780
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Passi per giocare:
È impossibile non dire Grazie per un lavoro come questo! Si spera che un giorno avremo qualcosa di simile su altri bug.
Non piangere, è da molto tempo che non rispondo:
Sfortunatamente, l'uscita si è rivelata non solo zero, ma negativa...
Beh, perché negativo...
Non l'ho capito la prima volta, non l'ho capito la seconda volta, ma l'ho capito la terza volta.
Non posso farci niente se sono così tonto. Non è colpa tua.
Quindi, non si offenda, Sergei.
Lei ha una certa incomprensione dei termini asincrono e sincrono.
Quando si dice che una funzione è asincrona, significa che sarà eseguita non nel thread di esecuzione corrente, ma in qualche altro thread.
Chiamare una funzione asincrona come ChartSetInteger dal thread principale è veloce perché l'esecuzione effettiva avviene in un thread diverso.
D'altra parte, una chiamata di una funzione sincrona ChartGetInteger richiederà la sincronizzazione dei thread e questo può richiedere tempo aggiuntivo.
I ritardi sono particolarmente evidenti quando il thread parallelo aggiorna costantemente i dati della struttura del grafico (per esempio, quando l'utente sposta la finestra del grafico o scorre la storia).
Molto probabilmente, per semplicità e affidabilità, viene utilizzato un unico oggetto di sincronizzazione per la sua struttura di dati del grafico.
Si può cercare di migliorare la velocità di esecuzione usando la "segmentazione dei dati", ma d'altra parte ora si può incorrere in deadlock, o dati sotto-aggiornati, o rallentamenti in altri luoghi più critici.
In generale, è meglio non toccare qualcosa che sta già funzionando in modo stabile.
No. I metodi Get sono sincroni, ma possono essere raggruppati ed eseguiti simultaneamente, quindi la chiamata al metodo 1 Get o 100 è quasi identica.
I metodi Set sono asincroni, ma possono anche essere raggruppati per una maggiore efficienza.
Quindi è sempre meglio raggruppare "Set calls together" e "Get calls together" piuttosto che "Get / set / get / set / get / set".
Le chiamate asincrone sono più efficienti se il thread chiamante non è bloccato mentre la funzione è in esecuzione, ma si perdono questi benefici se si mescolano Get e Set.
Spero che questo aiuti, nonostante la traduzione.
Da quanto ho capito - Get è sincrono, poiché restituisce il risultato richiesto. Ma se avete Set asincrono nella coda, dovete sincronizzarvi con loro.
Se ci sono solo i Get nella coda, non c'è ritardo.
Grazie a tutti. Sto lentamente iniziando a prenderci la mano.
Ora il vero quadro di questi ritardi diventa chiaro.
Come ho capito (correggetemi, per favore, se mi sbaglio):
Quando il metodo Get viene chiamato dal thread principale, c'è una richiesta al thread del grafico stesso, che gira in parallelo al thread principale. Ma il thread principale è controllato direttamente dal thread principale tramite i metodi Set e il thread principale dovrebbe già conoscere lo stato attuale del thread grafico, ma semplicemente non conosce lo stato attuale del thread grafico e non è sicuro se gli ultimi comandi sono stati eseguiti. Ecco perché avviene questa richiesta, per assicurarsi che tutti i comandi precedenti siano stati eseguiti. Dato che il metodo Get è sincrono, aspetta fino a quando una risposta viene ricevuta dal thread del grafico parallelo. Questo è il motivo dei ritardi.
Se non ho fatto un errore, sorge una domanda:
Perché il thread principale non può segnalare al thread che il suo comando è stato eseguito, in modo che il thread principale possa contrassegnare il comando come eseguito e aggiornare la sua tabella interna? Poi il thread principale restituirebbe i dati dalla tabella senza fare richieste al thread principale. Inoltre, si potrebbe passare un flag che dice che ci sono comandi non ancora eseguiti al thread parallelo o che tutti i comandi sono stati eseguiti per capire lo stato attuale del grafico. Non ci saranno ritardi con questo schema.
Ho implementato circa un meccanismo simile nella classe iCanvas.
Ecco un indicatore che dimostra questo meccanismo, dove c'è una funzione incredibilmente lenta ChartXYToTimePrice per associare le coordinate dei pixel al tempo e al prezzo del grafico e creare il suo analogo, la funzione XYToTimePrice, che aggiorna le sue variabili statiche interne all'evento CHARTEVENT_CHART_CHANGE e calcola i parametri richiesti in base ai dati di questo grafico statico dei parametri del grafico.
Grazie a tutti. Sto lentamente iniziando a prenderci la mano.
...Questo è vero. E, come ha detto Renat, il sistema di cache deve essere implementato sul lato mql. Forse potrebbe essere implementato sul lato della piattaforma, ma ciò comprometterebbe il raggiungimento dell'architettura multithreaded più produttiva possibile.
Capisco.
Tanto meglio per quelli che capiscono come implementare questo sistema di cache, e peggio per quelli che non lo fanno.
Cercherò di usare un'analogia, se non funziona così, allora così sia.
È tutto molto esagerato e non vero, ma comunque.
Ci sei tu, il cliente, che determina e porta i colori all'artista, e c'è l'artista, che usa i colori che porti e dipinge con essi sulla tela.
Dopo aver portato le vernici, siete liberi di andare per i vostri affari: lavoro, casa, scuola, .....
Potete anche visitare il pittore in qualsiasi momento e controllare il risultato.
Tuttavia, se venite per un'ispezione e l'artista sta dipingendo, dovrete aspettare che l'artista finisca il suo lavoro.
Il miglior modo di interagire è quello di portare al pittore tutti i colori di cui ha bisogno, ordinargli di dipingere e poi andare per i fatti tuoi.
Alla fine, se necessario, si può visitare il pittore per ispezioni tutte le volte necessarie per accedere alle tele.
Il modo più sub-ottimale di interagire è quello di portare al pittore una vernice alla volta e poi pretendere il risultato subito, aspettando che il pittore completi il suo lavoro ogni volta.
Qual è il problema del 2485 rispetto alla costruzione del 2009:
Artista si è spostato più vicino a voi, il tempo di viaggio per l'ispezione ha cominciato a spendere meno, che è un vantaggio.
Tuttavia, l'artista ha iniziato a dedicare molto tempo al lavoro "part-time" sul lato.
Prima prendeva "lavori part-time" con la stessa frequenza, ma ora bisogna aspettare troppo a lungo che l'artista completi il lavoro.
Capisco.
Tanto meglio per quelli che capiscono come implementare questo sistema di cache, e peggio per quelli che non lo fanno.
Il modo migliore per interagire è quello di portare al pittore tutte le vernici di cui avete bisogno, ordinargli di dipingere e poi andare per i fatti vostri.
Alla fine, se necessario, puoi visitare il pittore per un'ispezione tutte le volte che vuoi - avrai libero accesso alla tela.
Secondo me il modo migliore è quello di concordare con l'artista che appena finisce un quadro indicherà un particolare lavoro completato sul suo sito che è disponibile per la visualizzazione e anche d'accordo che indicherà il suo stato attuale - se sta facendo un lavoro part-time o libero.
Allora saprai quale quadro è pronto e quale no senza visitare l'artista e se l'artista è occupato o libero al momento, puoi mandargli il prossimo lavoro. E non ci sarà bisogno di viaggiare invano con un'ispezione. Risparmierà tempo e nervi sia per il cliente che per l'artista.
1) Nella mia mente, il modo migliore è quello di concordare con l'artista,
2) non appena finisce qualche pittura regolare,
3) poi ha immediatamente indicato un lavoro specifico fatto sul loro sito, che è disponibile per la visualizzazione da parte del cliente,
4) così come accettare di specificare sul sito del suo stato attuale - è occupato moonlighting o libero.
5) Poi il cliente saprà .... Se l'artista è attualmente occupato o libero e puoi inviargli il prossimo lavoro.
6) E non ci sarà bisogno di viaggiare invano con l'ispezione. Risparmierà tempo e nervi sia per il cliente che per l'artista.
1) L'artista non conosce i tuoi piani e nemmeno tu conosci il futuro...
2) Non ci sono quadri, c'è una sola tela su cui va tutta la manipolazione e l'"armeggio".
3) Introdurre processi estranei al materiale di partenza in un'analogia è non capire cos'è un'analogia e a cosa serve.
4) Un pittore non conosce il futuro e se dovete venire per un'ispezione, il suo stato può cambiare cento volte durante il viaggio.
5) Puoi portare la vernice in qualsiasi momento, ci vuole sempre la stessa quantità di tempo indipendentemente dallo stato dell'artista o dal suo impiego.
6) Di nuovo non capendo l'essenza di ciò che è un'analogia e a cosa serve...