[ARCHIVO]Cualquier pregunta de novato, para no saturar el foro. Profesionales, no lo dejéis pasar. No puedo ir a ningún sitio sin ti - 5. - página 383

 
Integer:


1. No por la suposición, sino por los resultados del experimento, que, por cierto, son confirmados por su experimento en la p. 378.

2. El código de la página 378 sólo proporciona acceso atómico. Las tareas no se ponen en cola para su ejecución. Puede ocurrir que una de las tareas no se ejecute durante mucho tiempo.

La cola es creada por el sistema. Su orden no está garantizada. Puede tardar mucho tiempo en ejecutarse. ¿Existe otra forma en este algoritmo defectuoso que implique un orden especial de acceso a un recurso compartido? ¿No sabes cuándo vendrán los ticks en los diferentes gráficos, cuándo serán las señales en el TS, etc.? ¿Qué diferencia hay, entonces, en el orden en que se accede al recurso compartido? Si el módulo está pendiente en este algoritmo, entonces es correcto (que espere). Pero no es correcto, en el sentido de construir el algoritmo.

Lee a Richter. Ya ha descrito todo correctamente.

 
Zhunko:

1. La cola es puesta en cola por el sistema. 2. El orden de ejecución no está garantizado. Puede tardar mucho tiempo en ejecutarse.

3. ¿Qué, hay otra manera en este algoritmo defectuoso, que implica un orden especial de abordar el recurso común?

4. ¿No sabes cuándo vendrán los ticks en los diferentes gráficos, cuándo serán las señales en el TS, etc.?

5. ¿Qué diferencia hay entonces en el orden de acceso al recurso común? Si el módulo está pendiente en este algoritmo, entonces es correcto (que espere). Pero no es correcto, en el sentido de construir el algoritmo.

6. Lee a Richter. Ya ha descrito el camino correcto.


Vamos por una segunda ronda.

1. El sistema no sabe qué tarea se ha ejecutado realmente y cuál ha sido rechazada dentro de la propia tarea. Es decir, desde el punto de vista del sistema la tarea está hecha, pero como sólo dejamos una tarea y bloqueamos el resto, desde nuestro punto de vista sólo está hecha una tarea. Por ello, nuestro trabajo consiste en garantizar que las tareas se prioricen regularmente.

1 и 2. La cola está alineada, pero el orden no está adornado)))) Así que no está alineado, sino que sólo se proporciona acceso atómico,

3. ¿Por qué no? Todo está en manos del programador.

4. Todo está en manos del programador.

5. Si estuviera de pie. Pero no se sostiene. La tarea no se pone en cola, sólo se ejecuta o no. En el siguiente cierre (tick) es lo mismo, puramente del balón... no se sabe quién ganará primero, y el resto está fuera de juego.

6. ¿Por qué? Como puede ver, no siempre es útil leer libros inteligentes. Parece que has leído, pero no entiendes de qué estamos hablando. No he leído, pero entiendo.

 
Integer:


Vamos a repasarlo de nuevo.

1. El sistema no sabe qué tarea fue realmente completada y cuál fue rechazada dentro de la propia tarea. Es decir, desde el punto de vista del sistema la tarea se ha completado, pero como sólo hemos dejado una tarea y hemos bloqueado las demás, desde nuestro punto de vista sólo se ha completado una tarea. Por ello, nuestro trabajo consiste en garantizar que las tareas se prioricen regularmente.

1 и 2. La cola está alineada, pero el orden no está adornado)))) Así que no está alineado, sino que sólo se proporciona acceso atómico,

3. ¿Por qué no? Todo está en manos del programador.

4. Todo está en manos del programador.

5. Si lo hiciera. Pero no es así. La tarea no se pone en cola, sólo se ejecuta o no. En la siguiente cerradura (tick), de la misma manera, puramente de la bola... no se sabe quién ganará primero, y el resto está detrás del boro.

6. ¿Por qué? Como puede ver, no siempre es útil leer libros inteligentes. Parece que has leído, pero no entiendes de qué estamos hablando. No he leído, pero entiendo.

Esa es su obsesión por el código complejo. En lugar de simplificar, se retuerce el código complicado para romper la cola.

Yo tampoco quise leer a Richter durante mucho tiempo. Pero lo leí de todos modos. Las reglas para construir aplicaciones multihilo son sencillas. Lo principal es que sea sencillo. Esta es la conclusión de Richter. De lo contrario, pasará mucho más tiempo depurando que escribiendo. Por cierto, nunca he tenido que depurar una aplicación multihilo. Todo funcionó de inmediato.

 
Zhunko:

Esta es su obsesión por el código complejo. En lugar de simplificar, se retuerce el código complicado para romper la cola.

Yo tampoco quise leer a Richter durante mucho tiempo. Pero lo leí de todos modos. Las reglas para construir aplicaciones multihilo son sencillas. Lo principal es mantener la sencillez. Esta es la conclusión de Richter. De lo contrario, pasará mucho más tiempo depurando que escribiendo. Por cierto, nunca he tenido que depurar aplicaciones multihilo. Todo funcionó bien a la vez.


¿Qué tan complicado es? ¿Qué códigos complicados? Es el mínimo requerido por la tarea. Y su enfoque es noubertal. Todo lo que se haga debe funcionar de forma fiable, no confiando en el efecto del azar.

¿Qué tiene que ver Richter con esto? ¿Qué tiene esto que ver con los sistemas multihilo? Recuerda el problema original que inició esta conversación.

 
¿Puedes darme una pista? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) no está compilando;
 
Dimka-novitsek:
¿Puedes darme una pista? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) no está compilando;
No hay paréntesis al final.
 
Oh. Gracias!!!! Lo siento, y definitivamente no hay soporte. No lo vi de inmediato.
 
Dimka-novitsek:
¿Puedes darme una pista? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) no está compilando;
Necesitas un paréntesis de cierre más al final. Tienes que resolver esos problemas por ti mismo. El compilador generará una pista sobre un error. Debes estar muy atento a los paréntesis. Si escribes uno de apertura, escribe uno de cierre y luego entre ellos.
 
Integer:


¿Cuál es el problema? ¿Qué código complicado? Este es el mínimo requerido por la tarea. Y su enfoque es el enfoque nouber. Todo lo que se haga debe funcionar de forma fiable y garantizada, no a expensas de confiar en el efecto del azar.

¿Qué tiene que ver Richter con esto? ¿Qué tiene que ver con los sistemas multihilo? Recuerda el problema original que inició esta conversación.

Bien, escríbalo como quiera. No voy a convencerte de ello. Te he dicho todo lo que puedo.

La tarea original era hacer una sincronización para referirse al tamaño del depósito. El código que escribí lo resuelve perfectamente. Todo es como debe ser. Con un tiempo mínimo de referencia al recurso. Todos los módulos se procesarán casi en el mismo orden que las solicitudes, con pocas excepciones. Lo cual no es importante.

Especialmente destacado para usted. Esta es una de las reglas para las aplicaciones multihilo. Si tienes hilos que tardan mucho en ejecutarse, tienes que ponerlos en cola y es importante, es un algoritmo defectuoso. Tienes que rehacerlo. No se puede escribir así. Sin embargo, puedes hacer de todo. Escribe...

 
Zhunko:

1. Bien, escríbalo como quiera. No voy a persuadirte. Te he dicho todo lo que puedo.

2. Inicialmente, la tarea consistía en realizar la sincronización para referirse al tamaño del depósito.

El código que escribí lo resuelve perfectamente. Todo es como debe ser. Con un tiempo mínimo de referencia al recurso. Todos los módulos se procesarán casi en el mismo orden que las solicitudes.

4. Especialmente destacado para usted. Esta es una de las reglas para las aplicaciones multihilo. Si tienes hilos que tardan mucho en ejecutarse, tienes que ponerlos en cola y es importante, este es un algoritmo erróneo. Tienes que rehacerlo. No se puede escribir así. Sin embargo, puedes hacer de todo. Escribe...


1. No tenía preguntas para ti, no perestimes tu misión.

2. ¿La palabra favorita es "sincronicidad"? Es una tarea paralela secuencial.

3. Lo resuelve, pero no perfectamente. El método Nuber - Lamer lo resuelve.

4. ¡Co-coo, despierta!

Razón de la queja: