[ARCHIVIO]Qualsiasi domanda da principiante, per non ingombrare il forum. Professionisti, non passate oltre. Non posso andare da nessuna parte senza di te - 5. - pagina 391

 
Integer:


1. Sei bloccato. Ancora una volta. Il sistema non ha modo di sapere se un flusso è stato inattivo o se ha eseguito un'azione.

Il sistema non ha bisogno di saperlo. È il problema del filo. Sarà gestito in entrambi i casi. È garantito dal sistema. A meno che, ovviamente, non lo fermiate voi stessi con qualche bug nel codice.
 
Zhunko:
Il sistema non ha bisogno di saperlo. È un problema di flusso. Verrà elaborato comunque. È garantito dal sistema. A meno che, ovviamente, non lo fermiate voi stessi con qualche bug nel codice.


È chiaro da molto tempo che lei non sa affatto di cosa sta parlando.
 

Junko, perché stai anche solo cercando di fare un punto qui... e non sai nemmeno di cosa stai parlando. Tu vuoi il sistema, tu non vuoi il sistema... Non sai nemmeno di cosa stai parlando. Si tratta di risolvere il problema che è stato precedentemente delineato... e ora comincerete a dire che non è necessario... Hai già detto che non dovrebbe esistere un tale compito. Tu vai in giro nella tua testa e non te ne rendi conto, e ti metti nel ruolo di un guru.

 
Non è il flusso che conta, ma quello che fa, e non sempre lo fa. E devi dirigere quello che fa.
 
Integer:
Non è il filo che conta, ma quello che fa e non lo fa sempre. E bisogna gestire ciò che fa.

Ho scrittoqui:

Zhunko:

C'è un altro caso in cui è necessaria una coda. Ma non una coda di esecuzione dei thread, ma un ordine di elaborazione dei dati ricevuti dai thread (risultati del lavoro dei thread). Questo è il compito più frequente per le code.

Questo?

 
Zhunko:

Scrittoqui:

Questo?

Più o meno simile. Ma prima c'erano dichiarazioni del tipo che l'ordine non è affatto importante. E qui è stato generalmente dichiarato quando non solo i compiti devono essere eseguiti in modo uniforme, ma anche in una certa sequenza (se non eseguire, ma per raccogliere dati per l'ulteriore elaborazione, perché non si può scavare fino alla imprecisione delle dichiarazioni). Ora tocca a te rispondere - io so di averlo fatto... allora cosa è successo nelle ultime 10 pagine?
 
Per favore, è normale che quando si esegue 1 volta per anno di storia (300-400 trade) il tester crea un file di log che pesa fino a un gigabyte... ?
 
lottamer:
Per favore, è normale che quando si esegue 1 volta per anno di storia (300-400 trade) il tester crea un file di log che pesa fino a un gigabyte... ?

Fondamentalmente è ok :) Non così normale o non normale, fa solo questo, tutto qui. Guardate cosa dice, se ci sono messaggi di errore, è necessario intraprendere qualche azione con questi errori. Se ci sono messaggi informativi - è necessario disabilitarli (se c'è un interruttore) o commentare le chiamate alle funzioni Print()(), Comment(), Alert().
 
Integer:

Più o meno lo stesso. Tuttavia, prima c'erano dichiarazioni del tipo che l'ordine non è affatto importante. E qui è più importante, quando non solo i compiti devono essere eseguiti in modo uniforme, ma anche in una certa sequenza (se non per eseguire, ma per raccogliere dati per l'ulteriore elaborazione, altrimenti si può confondere con l'imprecisione delle dichiarazioni). Ora tocca a te rispondere - io so di averlo fatto... allora cosa è successo nelle ultime 10 pagine?

Quello che è successo è dovuto alla mancanza di spiegazioni da parte vostra. Ha scritto di nuovo a pagina 381. Se avessi letto la mia risposta l'avresti notato e avresti detto.

===================

1. Ci sono diversi fili indipendenti.

2. I risultati sono impilati in una coda.

3. Questa coda è una risorsa condivisa.

4. È necessario sincronizzare l'accesso dei thread alla coda dei risultati condivisa.

Giusto?

===================

Questo è il modo in cui dovrebbe funzionare correttamente senza rimuovere la variabile globale:

#property show_inputs

extern int Pause = 1000;

int    hwndChart = NULL; // Уникальный идентификатор скрипта.
string sName = "Condition";

void init()
 {
  hwndChart = WindowHandle(Symbol(), 0);
  // Создаём глобальную переменную синхронизации скриптов.
  if (!GlobalVariableCheck(sName)) GlobalVariableSet(sName, 0);
 }
 
void deinit()
 {
  while (!IsStopped())
   {
    if (!GlobalVariableSetOnCondition(sName, hwndChart, 0)) continue;
    if (GlobalVariableSetOnCondition(sName, 0, hwndChart)) return;
   }
 }

void start()
 {
  while (!IsStopped())
   {
    Sleep(200); // Имитация тика.
    // Начало блока синхронизации.
    if (!GlobalVariableSetOnCondition(sName, hwndChart, 0)) continue;
    if (GlobalVariableGet(sName) == hwndChart)
     {
      Print("Start");
      Sleep(Pause); // Имитация работы.
      Print("End");
     }
    GlobalVariableSetOnCondition(sName, 0, hwndChart);
   } // Завершение блока синхронизации.
 }

Chiripaha:

Questo...

Credo che Arles abbia trovato la risposta alla domanda, dato che non sono ancora in grado di afferrare immediatamente il succo della soluzione. Ma questo è perché sono un principiante e ho bisogno di più tempo per imparare prima la teoria e poi provare la pratica. Ma cercherò di padroneggiare la questione.


Giusto, per questione irrisolta intendevo esattamente questa lista di domande.

................

====================================

Cioè, in altre parole. - Se non c'è nessun blocco di soluzione suggerito da voi nell'EA, allora l'utilizzo di molti EA di questo tipo può causare la situazione descritta nella domanda sulla gestione del rischio?

Lasciatemi spiegare un po' di più. Non sono sicuro che sia troppo critico. Perciò l'ho considerato finora in modo ipotetico. Perché la velocità di risoluzione dei problemi è alta e probabilmente le soluzioni nel computer "voleranno attraverso" l'ampio canale di bitrate del computer. - Ma forse mi sbaglio su questo, perché secondo Arles - ottiene solo 2 ordini per turno. Quindi c'è un problema.

Solo ora ho capito la domanda :-))

Se questo accade, è un problema con il rischio sbagliato. Non c'è bisogno di sincronizzare nulla se il rischio è basso. +-0,0001% del deposito non è cruciale.

 

Zhunko:

Solo ora ho capito la domanda :-))

Se questo accade, è un problema con il rischio sbagliato. Con un rischio basso non c'è bisogno di sincronizzare nulla. +-0,0001% del deposito non è cruciale.

Succede... Quando una persona è impegnata nella soluzione di qualche problema attuale (questione), è difficile passare la mente ad altri compiti. E quando ci sono molti compiti è difficile fare tutto... : )) Regole di gestione del tempo.

Un'altra domanda sul multithreading.

Il tutorial di Sergei Kovalev descrive un metodo con Squaredness ottimizzato dove l'Expert Advisor lavorerà in un ciclo. Se consideriamo questo e il multi-threading, ho capito bene che questo tipo di comportamento ciclico dell'EA non causerà svantaggi per altri EA, script e indicatori? E possiamo tranquillamente iniziare il lavoro dell'EA in un ciclo? O sarebbe meglio non farlo? E quando dovrebbe essere evitato?

Per quanto ho capito, questo ciclo di lavoro è implementato nel codice qui sopra. Forse è per questo che me lo sono ricordato.

E a proposito, se un tale EA in loop viene eseguito in tester, quanto sarà corretto? O dobbiamo "spegnere" il ciclo in questo caso?