Que garantias os sistemas operacionais "soft" em tempo real realmente fornecem

Eu acho que sei o que é um sistema operacional "rígido" em tempo real. É um sistema operacional com um agendador que fornece um contrato com o programador de aplicativos. Um aplicativo fornece um prazo para cada solicitação de alocação de recursos. Se as solicitações de prazo final forem possíveis , o planejador garante que cada recurso seja alocado para o aplicativo solicitante antes do prazo final. A garantia é suficiente para permitir que um programador de aplicativos raciocine sobre as latências máximas e as taxas de transferência mínimas de solicitações específicas.

Todas as definições que eu acho de sistemas em tempo real "suaves" parecem vazias para mim. Wikipedia diz

a utilidade de um resultado diminui após o prazo, degradando a qualidade do serviço do sistema.

Uhhhh. OK. Por esse critério, o Windows 95 era um sistema em tempo real suave, o 3BSD e o Linux também. A Wikipedia não é uma ótima fonte, mas os próximos hits do Google não são muito melhores. Por exemplo, http://users.ece.cmu.edu/~koopman/des_s99/real_time/ diz

Em um sistema flexível em tempo real, uma operação degradada em um pico de carga que raramente ocorre pode ser tolerada.

Isso não é um contrato, é uma maneira elegante de não dizer nada.

Quais são os exemplos de garantias / contratos reais em tempo real oferecidos por sistemas operacionais reais?

Estou procurando respostas do formulário:

Em (nome do SO), se o programador faz (o que o programador precisa fazer), o sistema operacional garante (o que o sistema garante).

Você acertou e a Wikipedia é o mais informativa possível - tempo real suave não é uma caracterização formal, é um julgamento de valor. Outra maneira de dizer "tempo real suave" é "eu gostaria que fosse em tempo real", ou talvez com mais precisão "deve ser em tempo real, mas é muito difícil".

Se você realmente deseja expressar sob a forma de uma garantia, é uma garantia do melhor esforço, em vez de uma garantia de desempenho específico.

Ou, para citar as Perguntas frequentes do Erlang (Erlang é uma linguagem de programação originalmente projetada para uso em telefonia):

O que significa soft realtime?

Os cínicos dirão "basicamente nada".

(...) Muitos sistemas de telecomunicações têm requisitos menos rígidos [do que em tempo real], por exemplo, eles podem exigir uma garantia estatística ao longo de "uma pesquisa de banco de dados leva menos de 20ms em 97% dos casos". Sistemas em tempo real, como o Erlang, permitem que você faça esse tipo de garantia.

E isso fornece uma definição útil. Tempo real suave indica um design que é otimizado para cada tarefa individual, levando não mais do que uma certa quantidade de tempo , em vez de otimizar o tempo total gasto para executar todas as tarefas. Por exemplo, um sistema flexível em tempo real teria como objetivo concluir 99,9% das solicitações em 10ms e processar 100 solicitações por segundo, onde um tempo não real poderia tentar prosseguir 200 solicitações por segundo, mas permitir que solicitações ocasionais bloqueiem 50 ms ou mais. Um tempo real difícil garantiria uma solicitação a cada 15ms, não importa o quê.

O tempo real suave é usado para aplicativos em que um prazo não cumprido significa uma degradação do serviço, mas não é crítico para o desempenho. Multimídia e telefonia são alguns casos de uso típicos. Cada quadro de áudio ou vídeo deve ser renderizado em tempo, ou deve ser ignorado; mas pular um quadro não é o fim do mundo. Os projetistas de Erlang tinham objetivos semelhantes em relação à confiabilidade em outros assuntos: observaram que era melhor para uma central telefônica, ocasionalmente, encerrar uma ligação, mas para ter certeza absoluta de que a central como um todo continuaria funcionando da melhor maneira possível do que para risco de falha catastrófica ao tentar manter as conexões a todo custo.

Por outro lado, algo como controlar um motor exige que o software nunca perca um prazo. Isso tem custos: o desempenho geral geralmente é mais lento e apenas comportamentos relativamente simples podem ser alcançados. Do outro lado do espectro, um aplicativo de processamento de números normalmente se preocupa apenas com o desempenho geral - o que importa é a rapidez com que as matrizes 1000x1000 são multiplicadas, e não a rapidez com que cada coluna é calculada.

O Linux com o conjunto de patches -rt (tempo real) fornece um agendador que fornece uma garantia interessante que parece não ser vazia. (Embora eu não esteja claro sobre como a garantia pode ser posta em uso real.)

A SCHED_FIFOpolítica de agendamento do Linux-rt funciona da seguinte maneira: O usuário atribui uma prioridade a todos os processos. (Os números de prioridade para os processos em "tempo real" são de 0 a 99, e os nicevalores tradicionais do Unix , de 20 a 19, são mapeados para as prioridades de 100 a 139. (Portanto, "0" é a prioridade "mais alta" e "139" é a "mais baixa " prioridade.)

A garantia é que, a qualquer momento, o planejador agendará os Ntrabalhos executáveis ​​de maior prioridade em uma Nmáquina processadora. Foram feitos grandes esforços para evitar problemas de inversão de prioridade dentro do kernel. Quando o processo Ase tornar executável e tiver uma prioridade mais alta do que qualquer outro processo em execução B, a prioridade Aserá imediata B.

Observe, no entanto, que não há garantias de tempo rigorosas fornecidas. O tempo gasto realmente realizando a preempção poderia, teoricamente, ser arbitrariamente longo. Além disso, parece haver algumas maneiras pelas quais um trabalho de baixa prioridade poderia iniciar um monte de E / S de longa latência. Quando a E / S conclui, os manipuladores de interrupção para o trabalho de baixa prioridade podem interromper um trabalho de prioridade mais alta, que é, sem dúvida, uma forma de inversão de prioridade.

Portanto, a garantia limitada fornecida é: se houver um único processo com a mais alta prioridade, sempre que for executável, ele obterá todos os recursos do processador que o sistema operacional pode fornecer de maneira realista. Se você tiver um bom limite superior na quantidade de recursos do processador consumidos pelo processo de maior prioridade, poderá calcular uma estimativa razoavelmente precisa dos recursos que estarão disponíveis para o segundo processo de maior prioridade, e assim por diante.

Um artigo detalhado que descreve o planejador em tempo real do Linux é http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Para definir "tempo real suave", é mais fácil compará-lo com "tempo real difícil".

Falando casualmente, a maioria das pessoas tem implicitamente um modelo mental informal que considera informações ou eventos como "em tempo real"

• se, ou na medida em que isso, for manifestado a eles com um atraso (latência) que possa estar relacionado à sua moeda percebida

• ou seja, em um período de tempo em que as informações ou eventos tenham um valor aceitável satisfatório para eles.

Existem inúmeras definições ad hoc diferentes de "tempo real difícil", mas nesse modelo mental, tempo real difícil é representado pelo termo "se". Especificamente, supondo que as ações em tempo real (como tarefas) tenham prazos de conclusão, o valor aceitável aceitável do evento que todas as tarefas concluídas é limitado ao caso especial em que todas as tarefas cumprem seus prazos.

Sistemas rígidos em tempo real fazem suposições muito fortes de que tudo sobre o aplicativo, o sistema e o ambiente é estático e conhecido a priori - por exemplo, quais tarefas são periódicas, horários de chegada, períodos e prazos, que eles venceram possui conflitos de recursos e, em geral, a evolução do tempo do sistema. Em um sistema de controle de voo de aeronave ou sistema de freio automotivo e em muitos outros casos, essas premissas geralmente podem ser satisfeitas para que todos os prazos sejam cumpridos.

Esse modelo mental é deliberada e muito útil o suficiente para abranger tanto o tempo real quanto o real - o soft é acomodado pela frase "na medida em que". Por exemplo, suponha que o evento de conclusão da tarefa tenha um valor abaixo do ideal, mas aceitável, se

• não mais de 10% das tarefas perdem seus prazos
• ou nenhuma tarefa está atrasada em mais de 20%
• ou o atraso médio de todas as tarefas não ultrapassa 15%
• ou o atraso máximo entre todas as tarefas é inferior a 10%

Todos esses são exemplos comuns de casos simples em tempo real em muitas aplicações.

Considere o aplicativo de tarefa única de buscar seu filho depois da escola. Provavelmente, esse prazo não tem um prazo real; em vez disso, você e seu filho terão algum valor com base em quando esse evento ocorrerá. Muito cedo desperdiça recursos (como seu tempo) e muito tarde tem algum valor negativo, pois seu filho pode ser deixado sozinho e potencialmente prejudicial (ou pelo menos incomodado).

Diferentemente do caso especial estático em tempo real rígido, o tempo real suave faz apenas as suposições mínimas específicas do aplicativo necessárias sobre as tarefas e o sistema, e são esperadas incertezas. Para pegar seu filho, você precisa ir até a escola, e o tempo para fazer isso é dinâmico, dependendo do clima, das condições do tráfego etc. Você pode ficar tentado a provisionar demais o sistema (por exemplo, permitir o que você espera que seja o no pior caso, o tempo de condução), mas novamente isso está desperdiçando recursos (seu tempo e ocupando o veículo da família, possivelmente negando o uso por outros membros da família).

Esse exemplo pode não parecer caro em termos de desperdício de recursos, mas considere outros exemplos. Todos os sistemas de combate militar são leves em tempo real. Por exemplo, considere realizar um ataque de aeronave a um veículo terrestre hostil usando um míssil guiado com atualizações para ele como manobras de destino. A satisfação máxima para concluir as tarefas de atualização do curso é alcançada por um ataque destrutivo direto no alvo. Mas uma tentativa de provisionar recursos em excesso para garantir esse resultado geralmente é muito cara e pode até ser impossível. Nesse caso, você pode ficar menos satisfeito o suficiente se o míssil atingir um alvo suficientemente próximo do alvo para desativá-lo.

Obviamente, os cenários de combate têm muitas incertezas dinâmicas possíveis que devem ser acomodadas pelo gerenciamento de recursos. Sistemas leves em tempo real também são muito comuns em muitos sistemas civis, como automação industrial, embora obviamente os militares sejam os mais perigosos e urgentes para obter um valor aceitável satisfatório.

A pedra angular dos sistemas em tempo real é a "previsibilidade". O caso difícil em tempo real está interessado em apenas um caso especial de previsibilidade - ou seja, que todas as tarefas cumpram seus prazos e o valor máximo possível será alcançado por esse evento. Esse caso especial é chamado de "determinístico".

Existe um espectro de previsibilidade; a maioria dos sistemas em tempo real (ou seja, soft) possui previsibilidade não determinística, por exemplo, do tempo de conclusão das tarefas e, portanto, dos valores obtidos com esses eventos. Em geral, a previsibilidade e, portanto, o valor, podem ser feitos o mais próximo possível do ponto final determinístico, mas a um preço que pode ser fisicamente impossível ou excessivamente caro (como em combate ou talvez em buscar seu filho na escola).

O tempo real flexível requer uma escolha específica de aplicativo de um modelo de probabilidade (não o modelo freqüente comum) e, portanto, de previsibilidade para raciocinar sobre latências de eventos e valores resultantes.

Voltando à lista acima de eventos que fornecem valor aceitável, agora podemos adicionar casos não determinísticos, como

• a probabilidade de que nenhuma tarefa perca seu prazo em mais de 5% é maior que 0,87.

Em um aplicativo de defesa antimísseis, considerando que o ataque sempre tem vantagem sobre a defesa, qual desses dois cenários de computação em tempo real você prefere:

• como a destruição perfeita de todos os mísseis hostis é muito improvável ou impossível, atribua seus recursos defensivos para maximizar a probabilidade de que muitos dos mísseis hostis mais ameaçadores (por exemplo, com base em seus alvos) sejam interceptados com sucesso (a intercepção próxima conta porque pode mover o míssil hostil fora do curso);

• reclame que esse não é um problema de computação em tempo real porque é dinâmico, em vez de estático, e os conceitos e técnicas tradicionais em tempo real não se aplicam; portanto, você não está interessado em fazer pesquisa e desenvolvimento para soft-time em tempo real.

Apesar dos vários mal-entendidos sobre soft time em tempo real na comunidade de computação em tempo real (mas não em outros campos não computacionais), o soft time em tempo real é muito geral e poderoso, e potencialmente muito complexo em comparação com o rígido em tempo real.

Para responder diretamente à pergunta do OP:

• um sistema rígido em tempo real pode fornecer garantias determinísticas - geralmente que todas as tarefas cumprem seus prazos, a interrupção ou o tempo de resposta da chamada do sistema sempre será menor que x etc. - SE E SOMENTE SE SUGESTÕES muito fortes forem feitas e estiverem corretas tudo o que importa é estático e conhecido a priori (em geral, essas garantias para sistemas difíceis em tempo real são um problema de pesquisa aberto, exceto em casos bastante simples)

• um sistema flexível em tempo real não oferece garantias determinísticas, destina-se a fornecer a melhor oportunidade probabilística especificada analiticamente e previsibilidade de oportunidade que sejam viáveis ​​nas atuais circunstâncias dinâmicas, de acordo com critérios específicos da aplicação. Obviamente, o tempo real difícil é um caso especial simples de tempo real suave. Obviamente, as garantias analíticas não determinísticas em tempo real podem ser muito complexas, mas são obrigatórias nos casos mais comuns em tempo real (incluindo os mais críticos e perigosos como o combate), pois a maioria dos casos é dinâmica e não estática.

Tenho uma discussão detalhada e muito mais precisa sobre tempo real, tempo real, tempo real, tempo real suave, previsibilidade, determinismo e tópicos relacionados no meu site real-time.org .