[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 383
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
1. la file d'attente est mise en attente par le système. 2. L'ordre dans lequel il est exécuté n'est pas garanti. L'exécution peut prendre beaucoup de temps.
3. quoi, il existe une autre voie dans cet algorithme défectueux, qui implique un ordre particulier d'adressage de la ressource commune ?
4. vous ne savez pas quand les ticks sur les différents graphiques arriveront, quand les signaux dans le TS seront, etc ?
5. Quelle différence cela fait-il alors de savoir dans quel ordre on accède à la ressource commune ? Si le module est en attente dans cet algorithme, alors c'est correct (laissez-le attendre). Mais pas correct, dans le sens de la construction de l'algorithme.
6. Lis Richter. Il a déjà décrit le bon chemin.
Allons-y pour un deuxième tour.
1. Le système ne sait pas quelle tâche a été réellement exécutée et quelle tâche a été rejetée dans la tâche elle-même. C'est-à-dire que du point de vue du système, la tâche est terminée, mais comme nous n'avons laissé qu'une seule tâche et bloqué le reste, de notre point de vue, une seule tâche est terminée. Il nous incombe donc de veiller à ce que les tâches soient régulièrement classées par ordre de priorité.
1 и 2. La file d'attente est alignée mais l'ordre n'est pas garni)))). Il n'y a donc pas d'alignement, mais seulement un accès atomique,
3. Pourquoi pas ? Tout est entre les mains du programmeur.
4. Tout est entre les mains du programmeur.
5. Si elle était debout. Mais elle ne tient pas. La tâche n'est pas mise en file d'attente, elle est simplement exécutée ou non. Au prochain verrou (tic), c'est la même chose, purement du ballon... on ne sait pas qui gagnera le premier, et les autres sont hors limites.
6. Pourquoi ? Comme vous pouvez le constater, il n'est pas toujours utile de lire des livres intelligents. Vous semblez avoir lu, mais vous ne comprenez pas ce dont nous parlons. Je n'ai pas lu, mais je comprends.
Revoyons tout ça.
1. Le système ne sait pas quelle tâche a été réellement achevée et quelle tâche a été rejetée au sein même de la tâche. C'est-à-dire que, du point de vue du système, la tâche a été achevée, mais comme nous n'avons laissé qu'une seule tâche et bloqué les autres, de notre point de vue, une seule tâche a été achevée. Il nous incombe donc de veiller à ce que les tâches soient régulièrement classées par ordre de priorité.
1 и 2. La file d'attente est alignée mais l'ordre n'est pas garni)))). Il n'y a donc pas d'alignement, mais seulement un accès atomique,
3. Pourquoi pas ? Tout est entre les mains du programmeur.
4. Tout est entre les mains du programmeur.
5. Si je l'ai fait. Mais ce n'est pas le cas. La tâche n'est pas mise en file d'attente, elle est simplement exécutée ou non. Sur la serrure suivante (tick), de la même manière, purement de la balle... on ne sait pas qui gagnera en premier, et les autres sont derrière le bore.
6. Pourquoi ? Comme vous pouvez le constater, il n'est pas toujours utile de lire des livres intelligents. Vous semblez avoir lu, mais vous ne comprenez pas ce dont nous parlons. Je n'ai pas lu, mais je comprends.
C'est ton obsession pour le code complexe. Au lieu de le simplifier, vous déformez un code compliqué pour casser la file d'attente.
Pendant longtemps, je n'ai pas voulu lire Richter non plus. Mais je l'ai lu quand même. Les règles de construction des applications multithreads sont simples. L'essentiel est de rester simple. C'est la conclusion de Richter. Sinon, vous passerez beaucoup plus de temps à déboguer qu'à écrire. À propos, je n'ai encore jamais eu à déboguer une application multithread. Tout a fonctionné immédiatement.
C'est ton obsession pour le code complexe. Au lieu de simplifier, vous déformez le code compliqué pour casser la file d'attente.
Pendant longtemps, je n'ai pas voulu lire Richter non plus. Mais je l'ai lu quand même. Les règles de construction des applications multithreads sont simples. L'essentiel est de rester simple. C'est la conclusion de Richter. Sinon, vous passerez beaucoup plus de temps à déboguer qu'à écrire. À propos, je n'ai encore jamais eu à déboguer des applications multithreads. Tout a bien fonctionné en même temps.
Est-ce que c'est compliqué ? Quels codes compliqués ? C'est le minimum requis par la tâche. Et votre approche est noubertale. Tout ce qui est fait doit fonctionner de manière fiable, sans compter sur l'effet du hasard.
Qu'est-ce que Richter a à voir avec ça ? Qu'est-ce que cela a à voir avec les systèmes multithreads ? Rappelez-vous le problème initial qui a déclenché cette conversation.
Pouvez-vous me donner un indice ? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) ne se compile pas ;
Pouvez-vous me donner un indice ? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) ne se compile pas ;
Quel est le problème ? Quel code compliqué ? C'est le minimum requis par la tâche. Et votre approche est l'approche nouber. Tout ce qui est fait doit fonctionner de manière fiable et garantie, et non au prix d'un recours à l'effet du hasard.
Qu'est-ce que Richter a à voir avec ça ? Qu'est-ce que cela a à voir avec les systèmes multithreads ? Rappelez-vous le problème initial qui a déclenché cette conversation.
Bien, écrivez-le comme vous voulez. Je ne vais pas te convaincre de le faire. Je vous ai dit tout ce que je pouvais.
La tâche initiale était de faire une synchronisation pour se référer à la taille du dépôt. Le code que j'ai écrit résout parfaitement le problème. Tout est comme il se doit. Avec un minimum de temps de référence à la ressource. Tous les modules seront traités pratiquement dans le même ordre que les demandes, à quelques exceptions près. Ce qui est sans importance.
Je l'ai surligné pour vous spécifiquement. C'est l'une des règles pour les applications multithreads. Si vous avez des fils qui mettent beaucoup de temps à s'exécuter, vous devez les mettre en file d'attente et c'est important, c'est un algorithme défectueux. Vous devez le refaire. Tu ne peux pas l'écrire comme ça. Mais vous avez le droit de tout faire. Écrire...
1. bien, écrivez-le comme vous voulez. Je ne vais pas vous persuader. Je vous ai dit tout ce que je pouvais.
2. au départ, la tâche consistait à effectuer une synchronisation pour se référer à la taille du dépôt.
Le code que j'ai écrit résout parfaitement le problème. Tout est comme il se doit. Avec un minimum de temps de référence à la ressource. Tous les modules seront traités presque dans le même ordre que les demandes.
4. Spécialement mis en avant pour vous. C'est l'une des règles à respecter pour les applications multithreads. Si vous avez des threads qui prennent beaucoup de temps à s'exécuter, vous devez les mettre en file d'attente et c'est important, c'est un mauvais algorithme. Vous devez le refaire. Tu ne peux pas l'écrire comme ça. Mais vous avez le droit de tout faire. Écrire...
1. Je n'avais pas de questions pour vous, ne perestimez pas votre mission.
2. Le mot préféré est "synchronicité" ? Il s'agissait d'exécuter des tâches parallèles de manière séquentielle.
3. Résout le problème, mais pas parfaitement. La méthode Nuber - lamer le résout.
4. Coo-coo, réveille-toi !