[ARQUIVO]Qualquer pergunta de novato, para não desorganizar o fórum. Profissionais, não passem por ela. Não posso ir a lugar nenhum sem você - 5. - página 383

 
Integer:


1. Não a partir do pressuposto, mas a partir dos resultados do experimento, que, por sinal, são confirmados por seu experimento na p. 378.

2. O código na página 378 fornece apenas acesso atômico. As tarefas não estão enfileiradas para execução. Pode acontecer que uma das tarefas não seja executada por muito tempo.

A fila é criada pelo sistema. Seu pedido não é garantido. Pode levar muito tempo para ser executado. Existe outra forma neste algoritmo defeituoso que implica uma ordem especial de acesso a um recurso compartilhado? Você não sabe quando virão os carrapatos nos diferentes gráficos, quando virão os sinais no TS, etc.? Que diferença faz, então, em que ordem o recurso compartilhado será acessado? Se o módulo estiver pendente neste algoritmo, então ele está correto (deixe-o esperar). Mas não correto, no sentido de construir o algoritmo.

Leia Richter. Ele já descreveu tudo corretamente.

 
Zhunko:

1. A fila é enfileirada pelo sistema. 2. A ordem em que ela é executada não é garantida. A execução pode demorar muito tempo.

3. existe outra forma neste algoritmo defeituoso, que implica uma ordem especial de abordar o recurso comum?

4. você não sabe quando virão os carrapatos nos diferentes gráficos, quando serão os sinais no TS, etc.?

5. Que diferença faz, então, em que ordem o recurso comum será acessado? Se o módulo estiver pendente neste algoritmo, então ele está correto (deixe-o esperar). Mas não correto, no sentido de construir o algoritmo.

6. Leia Richter. Ele já descreveu o caminho certo.


Vamos para uma segunda rodada.

1. O sistema não sabe qual tarefa foi realmente executada e qual foi rejeitada dentro da própria tarefa. Isto é, do ponto de vista do sistema a tarefa é feita, mas como deixamos apenas uma tarefa e bloqueamos o resto, do nosso ponto de vista apenas uma tarefa é feita. Portanto, é nosso trabalho garantir que as tarefas sejam regularmente priorizadas.

1 и 2. A fila está alinhada, mas o pedido não é guardado)))) Portanto, não está alinhado, mas apenas o acesso atômico é fornecido,

3. por que não? Tudo está nas mãos do programador.

4. Tudo está nas mãos do programador.

5. Se estivesse de pé. Mas não se mantém. A tarefa não é enfileirada, apenas executada ou não. No próximo cadeado (tick) é o mesmo, puramente da bola... é desconhecido quem vai ganhar primeiro, e o resto está fora dos limites.

6. Por quê? Como você pode ver, nem sempre é útil ler livros inteligentes. Você parece ter lido, mas não entende do que estamos falando. Eu não li, mas entendo.

 
Integer:


Vamos rever isso novamente.

1. O sistema não sabe qual tarefa foi realmente concluída e qual foi rejeitada dentro da própria tarefa. Isto é, do ponto de vista do sistema, a tarefa foi concluída, mas como deixamos apenas uma tarefa e bloqueamos as outras, do nosso ponto de vista, apenas uma tarefa foi concluída. Portanto, é nosso trabalho garantir que as tarefas sejam regularmente priorizadas.

1 и 2. A fila está alinhada, mas o pedido não é guardado)))) Portanto, não está alinhado, mas apenas o acesso atômico é fornecido,

3. por que não? Tudo está nas mãos do programador.

4. Tudo está nas mãos do programador.

5. Se eu tivesse. Mas não. A tarefa não é enfileirada, é apenas executada ou não. Na próxima fechadura (tick), da mesma forma, puramente da bola... não se sabe quem vai ganhar primeiro, e os demais estão atrás do boro.

6. Por quê? Como você pode ver, nem sempre é útil ler livros inteligentes. Você parece ter lido, mas não entende do que estamos falando. Eu não li, mas entendo.

Essa é sua obsessão com códigos complexos. Em vez de simplificar, você torce o código complicado para quebrar a fila.

Eu também não queria ler Richter por muito tempo. Mas eu o li na mesma. As regras de construção de aplicações multi-tarefas são simples. O principal é manter as coisas simples. Esta é a conclusão de Richter. Caso contrário, você gastará muito mais tempo na depuração do que na escrita. A propósito, eu nunca tive que depurar uma aplicação multi-tarefa ainda. Tudo funcionou de imediato.

 
Zhunko:

Esta é sua obsessão com códigos complexos. Em vez de simplificar, você torce o código complicado para quebrar a fila.

Eu também não queria ler Richter por muito tempo. Mas eu o li na mesma. As regras de construção de aplicações multi-tarefas são simples. O principal é mantê-lo simples. Esta é a conclusão de Richter. Caso contrário, você gastará muito mais tempo na depuração do que na escrita. A propósito, eu nunca tive que depurar aplicações multi-tarefas ainda. Tudo funcionou bem de uma só vez.


Quão complicado é isso? Que códigos complicados? É o mínimo exigido pela tarefa. E sua abordagem é noubertal. Tudo o que é feito deve funcionar de forma confiável, não confiando no efeito do acaso.

O que o Richter tem a ver com isso? O que isso tem a ver com sistemas com múltiplas roscas? Lembre-se do problema original que iniciou esta conversa.

 
Você pode me dar uma dica? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) não está compilando;
 
Dimka-novitsek:
Você pode me dar uma dica? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) não está compilando;
Sem parênteses no final.
 
Oh. Obrigado!!!! Desculpe, e definitivamente sem parênteses. Eu não o vi imediatamente.
 
Dimka-novitsek:
Você pode me dar uma dica? Print(" Itogo_Profit",Itogo_Profit, " Profit_pomnim " , GlobalVariableGet("Profit_pomnim" ) não está compilando;
Você precisa de mais um parêntese de fechamento no final. Você tem que resolver tais problemas por si mesmo. O compilador irá gerar uma dica sobre um erro. Você deve estar muito atento aos parênteses. Se você escrever um de abertura, escreva um de fechamento e, em seguida, entre eles.
 
Integer:


Qual é o problema? Que código complicado? Este é o mínimo exigido pela tarefa. E sua abordagem é a nouber approach. Qualquer coisa feita deve funcionar de forma confiável, e não às custas de confiar no efeito do acaso.

O que Richter tem a ver com isso? O que isso tem a ver com sistemas multi-tarefa? Lembre-se do problema original que iniciou esta conversa.

Muito bem, escreva como quiser. Não vou convencê-lo. Já lhe disse tudo o que podia.

A tarefa original era fazer uma sincronização para se referir ao tamanho do depósito. O código que escrevi o resolve perfeitamente. Tudo é como deveria ser. Com o mínimo de tempo de referência ao recurso. Todos os módulos serão processados quase na mesma ordem que as solicitações, com poucas exceções. O que não é importante.

Destaquei-o especificamente para você. Esta é uma das regras para aplicações multi-tarefas. Se você tem fios que levam muito tempo para serem executados, você precisa enfileirá-los e isso é importante, é um algoritmo defeituoso. Você tem que refazê-lo. Não se pode escrever dessa maneira. Você pode fazer tudo, no entanto. Escreva...

 
Zhunko:

1. tudo bem, escreva como quiser. Eu não vou persuadi-lo. Já lhes disse tudo o que podia.

Inicialmente, a tarefa era fazer a sincronização para se referir ao tamanho do depósito.

O código que escrevi o resolve perfeitamente. Tudo é como deveria ser. Com o mínimo de tempo de referência ao recurso. Todos os módulos serão processados quase na mesma ordem que os pedidos.

4. Especialmente destacado para você. Esta é uma das regras para aplicações multi-tarefas. Se você tem fios que levam muito tempo para serem executados, você precisa enfileirá-los e isso é importante, este é um algoritmo errado. Você tem que refazê-lo. Não se pode escrever dessa maneira. Você pode fazer tudo, no entanto. Escreva...


1. Eu não tinha perguntas para você, não perestime sua missão.

2. palavra favorita é "sincronicidade"? Foi o rabo de executar tarefas paralelas sequencialmente.

3. Resolve-o, mas não perfeitamente. Nuber - o método lamer resolve isso.

4. Coo-coo, acorde!

Razão: