Skip to main content
Este tópico aborda as metas de design definidas ao criar o novo modelo de programação assíncrona do Microsoft Game Development Kit (GDK). Este tópico também aborda as melhorias feitas em relação ao modelo do XBOX One Software Development Kit, em resposta aos comentários dos desenvolvedores.

​
Neste tópico

​
Introdução

O Microsoft Game Development Kit (GDK) introduziu um novo modelo de programação assíncrona projetado para fornecer a você um comportamento de execução altamente personalizável e controlável, com baixa sobrecarga de processamento e memória. Todas as chamadas de API assíncronas no Microsoft Game Development Kit (GDK) usam esse modelo para oferecer consistência. No entanto, as bibliotecas assíncronas podem ser usadas diretamente nos seus próprios sistemas de tarefas e assíncronos para gerenciar o enfileiramento e o despacho de tarefas. Aprendendo com o modelo assíncrono anterior do XBOX One Software Development Kit e com os comentários dos desenvolvedores, a nova solução no Microsoft Game Development Kit (GDK) oferece a você controle total de como e onde as tarefas assíncronas são executadas. Você pode usar qualquer design de threading, seja com execuções síncronas em um único thread ou execuções paralelas em threads do título com prioridades e máscaras de afinidade altamente específicas. O XBOX One Software Development Kit usava apenas o pool de threads do sistema. A mudança de paradigma do Microsoft Game Development Kit (GDK) aprimora o que era a solução do XBOX One Software Development Kit usando APIs em C simples (flat-C) no estilo Win32 ou APIs C++ simples. Com isso, você pode gerenciar diretamente o momento da alocação e da desalocação de memória. O desempenho pode ser inspecionado com mais facilidade, e a maioria das chamadas de API (e todas as chamadas de API da biblioteca assíncrona usadas para execução de tarefas) vem com uma garantia de alto desempenho.

​
Metas de design

As bibliotecas assíncronas foram projetadas com algumas metas principais para garantir que os títulos obtenham o máximo de desempenho com o mínimo de sobrecarga da API ou do sistema. A lista a seguir contém algumas metas de alto nível.
  • O código assíncrono é consistente e fácil de entender e identificar.
  • Você tem liberdade para gerenciar completamente o comportamento de execução dos retornos de chamada.
  • Você pode usar threads como quiser.
  • O desempenho e o uso de memória são consistentes e fáceis de gerenciar.
  • A sobrecarga do sistema para executar tarefas é baixa e utilizável em threads principais.
  • As bibliotecas assíncronas não devem ser reservadas apenas para o uso de APIs do Microsoft Game Development Kit (GDK).
Algumas dessas metas são abordadas nas subseções a seguir e outras são abordadas na seção Melhorias em relação ao XBOX One Software Development Kit deste tópico.

​
Consistente e multiplataforma

A consistência oferece algumas das expectativas a seguir sobre como as APIs assíncronas são escritas e se comportam.
  • Métodos e dados são prefixados com X, seguido do nome da biblioteca.
  • Erros normais são relatados por meio de códigos de erro HRESULT.
  • Todas as chamadas assíncronas em todo o Microsoft Game Development Kit (GDK) usam um XAsyncBlock.
  • Os métodos de início assíncronos do Microsoft Game Development Kit (GDK) têm o sufixo Async.
  • Os métodos de resultado assíncronos do Microsoft Game Development Kit (GDK) têm o sufixo Result.
Ser multiplataforma significa que as mesmas chamadas de API assíncronas podem ser usadas em qualquer plataforma à qual o Microsoft Game Development Kit (GDK) se destina. Atualmente, essas plataformas incluem PC com Windows (tópico sob NDA), consoles da família XBOX One e consoles XBOX Series (tópico sob NDA). Seja usando as bibliotecas assíncronas para chamadas de API do Microsoft Game Development Kit (GDK) ou para sua própria funcionalidade, o processo é sempre o mesmo para configurar um XAsyncBlock e iniciar o método assíncrono. Sempre que um método assíncrono é fornecido por uma biblioteca, esses métodos usam as bibliotecas assíncronas para implementação. A tabela a seguir mostra algumas bibliotecas que expõem métodos assíncronos.

​
Controle total do desenvolvedor

Uma parte importante das novas bibliotecas assíncronas é que você tem controle total para permitir o melhor uso possível para o título. Isso significa que muitas partes do modelo são personalizáveis, incluindo as seguintes. Ao criar uma fila de tarefas, você pode personalizar como os retornos de chamada das duas portas são despachados, conforme mostrado na tabela a seguir. Você pode substituir a fila de tarefas padrão usada pelo título quando nenhuma fila de tarefas é especificada usando XTaskQueueSetCurrentProcessTaskQueue. Se quiser garantir que uma fila de tarefas seja sempre especificada, você também pode usar essa função com nullptr para remover a fila padrão. Ao fazer isso, um erro será gerado se uma fila de tarefas não for especificada. Se preferir usar sondagem nas chamadas assíncronas para saber quando a tarefa é concluída, você pode usar XAsyncGetStatus para verificar os códigos de retorno.

​
Qualquer situação de threading

Quando uma porta de fila de tarefas é configurada para usar o despacho manual, não há restrição sobre quando ou como a porta é despachada. As bibliotecas assíncronas são thread-safe em sua implementação, para que comportamentos personalizados de threading e simultaneidade possam ocorrer sem bloqueios. Seções críticas, operações interligadas e outras construções relacionadas a multithreading só são necessárias para proteger os dados do usuário usados nos retornos de chamada, e não os sistemas assíncronos. Ao usar seus próprios threads, você tem liberdade para definir máscaras de afinidade e prioridades de thread conforme a necessidade da sua implementação. Você também pode usar o loop de mensagens do Windows para lidar com o despacho. O comportamento de execução dos retornos de chamada de tarefas nas portas manuais depende completamente de como seus threads estão configurados para chamar XTaskQueueDispatch, conforme mostrado nas figuras 1 e 2. Figura 1. Mostra o comportamento de execução dos retornos de chamada de um thread Captura de tela do comportamento de execução dos retornos de chamada de um thread Figura 2. Mostra o comportamento de execução dos retornos de chamada de vários threads Captura de tela do comportamento de execução dos retornos de chamada de vários threads

​
Melhorias em relação ao XBOX One Software Development Kit

Responder aos seus comentários e aprimorar soluções anteriores é muito importante para o Microsoft Game Development Kit (GDK) (tópico sob NDA). As subseções a seguir listam algumas melhorias importantes feitas em comparação com a programação assíncrona no XBOX One Software Development Kit.

​
Sem C++/CLI (WinRT)

O XBOX One Software Development Kit exigia o uso de C++/CLI (WinRT) para o comportamento de funções assíncronas. Com isso, o sistema gerenciava suas chamadas para os XBOX services e outros serviços sem enfrentar problemas como vazamentos de recursos e erros. No entanto, isso também exigia aprender uma nova sintaxe de codificação e levar em conta a divisão de tempo implícita e o uso de recursos do sistema. O modelo assíncrono do Microsoft Game Development Kit (GDK) muda o paradigma para um modelo de API em estilo C no estilo Win32 para as bibliotecas assíncronas. O código do Microsoft Game Development Kit (GDK) pode ser usado diretamente em projetos C/C++ sem integrar o ecossistema WinRT gerenciado. Como resultado, todas as alocações e comportamentos ficam isolados e são bem compreendidos, com o mínimo de comportamento em segundo plano nos threads do sistema.

​
Controle total do comportamento de threading

O XBOX One Software Development Kit tinha uma única forma de lidar com chamadas assíncronas, que era executá-las simultaneamente em threads do pool do sistema. O nível de controle se limitava a ajustar o pool de threads do sistema. No Microsoft Game Development Kit (GDK), o threading pode usar o pool de threads do sistema, como descrito para o XBOX One Software Development Kit, ou ser personalizado com threading manual para criar o comportamento para o aplicativo. Com o threading manual, o comportamento de execução dos retornos de chamada é determinado por como e quando XTaskQueueDispatch é chamado. Se essa função for chamada em apenas um thread, o comportamento se tornará síncrono, executando nesse thread. Se vários threads chamarem a função simultaneamente, cada chamada obterá um retorno de chamada diferente da fila de tarefas e os executará em paralelo. Os diferentes comportamentos de execução dos retornos de chamada foram explicados na seção Controle total do desenvolvedor deste tópico.

​
Códigos de erro em vez de exceções

O Microsoft Game Development Kit (GDK) abrange muitas tecnologias, antigas e novas. Como resultado, o tratamento de erros pode variar de biblioteca para biblioteca. As bibliotecas assíncronas foram projetadas para serem “sem exceções”. Isso significa que exceções não são usadas para erros de chamada, controle de fluxo, relatório de status ou qualquer outra finalidade em tempo de execução. Você pode usar seu próprio tratamento de exceções no seu título. A maioria dos erros e códigos de status agora é relatada por meio de códigos HRESULT no estilo de codificação padrão do Win32. Quando o código de status do resultado não é importante, um booliano pode ser usado. Quando se espera que um método de API gere erros comuns, esses erros são listados na documentação com uma explicação de suas causas. Como são usados códigos HRESULT, um padrão simples para verificar os códigos é usar as macros SUCCESS() e FAILED() do Windows. Ao verificar códigos de erro específicos para determinar como prosseguir, você pode verificar o valor HRESULT. Para obter mais informações sobre o tratamento de erros no Microsoft Game Development Kit (GDK), consulte Tratamento de erros no Microsoft Game Development Kit.

​
Sem coleta de lixo

Como não há suporte a C++/CLI (WinRT) no Microsoft Game Development Kit (GDK), isso também significa que não há coleta de lixo ocorrendo em segundo plano durante o tempo de execução. Todas as alocações do sistema operacional rastreadas são representadas por objetos HANDLE diretos ou por typedefs de identificadores personalizados fornecidos pelas bibliotecas. Usando identificadores, você pode configurar o momento, o comportamento e o desempenho de alocação/desalocação para serem gerenciados pelo chamador. Essas alocações e desalocações podem ser transferidas para threads de carregamento de suporte para evitar travamentos de desempenho. A desalocação não acontece inesperadamente quando o desempenho é fundamental. No entanto, o rastreamento de recursos e a prevenção de vazamentos de memória passam a ser sua responsabilidade. Garanta que qualquer identificador alocado seja desalocado quando não for mais necessário.

​
Alto desempenho garantido

O modelo assíncrono do XBOX One Software Development Kit, com o uso do framework COM gerenciado, estava sujeito a oscilações inesperadas de memória e desempenho que às vezes eram difíceis de prever. No entanto, o modelo do Microsoft Game Development Kit (GDK) garante desempenho e consumo de memória consistentes. Como o threading pode ser controlado, o desempenho das chamadas do sistema pode ser inspecionado com mais facilidade usando um criador de perfil ou código personalizado. O exemplo Asynchronous Programming do ATG tem testes internos para medir parte do tempo gasto. O gráfico da figura 3 mede o tempo gasto gerenciando uma tarefa assíncrona com um provedor assíncrono personalizado. Os threads personalizados usados no teste executam os retornos de chamada o mais rápido possível. Figura 3. Mostra o gráfico que mede a sobrecarga do sistema assíncrono Captura de tela do gráfico que mede a sobrecarga do sistema assíncrono A sobrecarga do sistema é muito baixa. Os custos de sobrecarga ocorrem principalmente durante a espera para que os threads despachem as portas da fila de tarefas. O tempo geral da tarefa assíncrona, desconsiderando os custos de sobrecarga, é o trabalho real dentro dos retornos de chamada da tarefa.

​
Threads sensíveis ao tempo

Threads sensíveis ao tempo são uma nova especificação que o Microsoft Game Development Kit (GDK) usa para identificar threads do título que não devem ter operações de bloqueio nem operações inesperadamente longas. Um usuário pode marcar um thread do título como sensível ao tempo com uma chamada para XThreadSetTimeSensitive. Quando um thread é marcado como sensível ao tempo, qualquer invocação de método de API do Microsoft Game Development Kit (GDK) nesse thread que não forneça um desempenho de tempo de execução consistente e confiável (definido como não “seguro para sensibilidade ao tempo”) dispara uma asserção de depuração para você. Esses métodos seguros para sensibilidade ao tempo incluem as seguintes garantias no lado da implementação.
  • Nenhum carregamento ou inicialização sob demanda é realizado.
  • Nenhuma chamada é feita entre limites de VM ou de processo.
  • As alocações de memória são limitadas.
Com isso, os métodos seguros para sensibilidade ao tempo são executados em tempo consistente com as mesmas entradas e não causam picos inesperados de desempenho. Muitos métodos do Microsoft Game Development Kit (GDK) são marcados internamente como seguros para sensibilidade ao tempo, e os threads não precisam ser marcados como sensíveis ao tempo para obter a garantia ao chamar métodos seguros para sensibilidade ao tempo. A maioria dos métodos de API assíncronos é segura para sensibilidade ao tempo. Os que não são estão relacionados à configuração da fila de tarefas e a outras chamadas de baixa frequência que normalmente são invocadas no momento do carregamento ou da inicialização. Todos os métodos relacionados a iniciar, gerenciar, cancelar, concluir ou trabalhar diretamente de outra forma com tarefas assíncronas são seguros para sensibilidade ao tempo. Para obter mais informações sobre funções não seguras, consulte a seção Funções não seguras para threads sensíveis ao tempo do tópico Threads sensíveis ao tempo.

​
Uso genérico além das chamadas de API do Microsoft Game Development Kit (GDK)

As bibliotecas assíncronas do Microsoft Game Development Kit (GDK) são genéricas e não se limitam ao uso em chamadas de API. Qualquer chamada assíncrona fornecida pelo Microsoft Game Development Kit (GDK) usa as bibliotecas assíncronas internamente e fornece métodos consistentes para ações que incluem iniciar a tarefa e obter os resultados. Para obter mais informações sobre como usar as bibliotecas para finalidades que não envolvem APIs do GDK, consulte Código de exemplo. Com essa configuração, iniciar uma tarefa assíncrona é o mesmo processo, seja uma função do Microsoft Game Development Kit (GDK) ou um padrão personalizado: um XAsyncBlock é configurado para uma tarefa e, em seguida, a tarefa é iniciada. Iniciar a tarefa pode ser uma função de API do Microsoft Game Development Kit (GDK) ou um método personalizado do título. Fique à vontade para usar as bibliotecas assíncronas para qualquer finalidade assíncrona em todo o seu título.

​
Documentação de referência da API

​
Consulte também

Modelo de programação assíncrona Projetando a fila de tarefas
Last modified on October 6, 2026