A programação baseada em tarefas em C ++ exigiria novos recursos padrão de idioma?

Então, eu vi esse vídeo no Youtube com todos esses mestres em C ++ no GoingNative 2012: painel interativo, onde todos podiam fazer as perguntas.

Este é o vídeo que eu estava falando: GoingNative 2012 - Dia 1 - Painel Interativo: A importância de ser nativo

E, às vezes, 0:24:00 alguém fez uma pergunta muito interessante:

Fazemos programação simultânea há algum tempo usando pthreads, usando threads do Windows e assim por diante. Estou tão feliz que o C ++ e o C alcançaram a programação simultânea, mas parece-me que já está atrasado daqui a cinco anos ou dez anos, porque agora temos todos esses multicores poderosos e a programação desses multicores não deve ser baseada em threads, deve ser baseada em tarefas e a Microsoft [...] possui a biblioteca PPL e assim por diante, e isso é totalmente não refletindo no padrão C ++. [...] A única coisa que tenho medo é que o padrão possa ser bloqueado em threads e meio que dificulte a mudança para a programação baseada em tarefas ...

Agora sou novo nesses conceitos e estou um pouco confuso. O que é realmente programação baseada em tarefas . Este termo se refere à mesma coisa a que se refere à programação sem bloqueio ? Esses dois termos são equivalentes ou existem links entre eles?

— mosquito
fonte

Não tive a oportunidade de trabalhar com o padrão C ++ mais recente; portanto, isso pode ser muito diferente, mas é consistente com as preocupações da sua cotação. No meu vocabulário, uma tarefa é equivalente a um processo. Um processo / tarefa possui sua própria memória alocada. Processos diferentes não podem acessar a memória / dados de outro processo (pelo menos sem pular os bastidores). Um thread pode acessar a memória / dados de outros threads em execução no mesmo processo. Assim, em um sistema multicore, os processos podem ser executados em CPUs separadas sem problemas, mas os threads precisariam se coordenar entre si ao acessar dados / memória compartilhados.

— Dunk

... criando, assim, a necessidade de saltar em bastidores em um sistema multicore se os encadeamentos estiverem sendo executados em CPUs diferentes. Isso já é difícil o suficiente com um programador em loop, é duvidoso que o hardware / compilador consiga lidar com o caso genérico de maneira confiável e eficiente.

— Dunk

Obrigado a todos por todas essas respostas legais, mas ainda há uma pergunta sem resposta:

Does this term refer to the same thing that Lock-Free Programming refers to? Are these two equivalent terms or are there any links between them?

alguém pode explicar? Todas essas bibliotecas baseadas em tarefas também são construídas sobre encadeamentos ou há outra maneira de serem implementadas? Obrigado!

Respostas:

A Microsoft possui a "Biblioteca Paralela de Tarefas" ou TPL.

É uma abstração de nível superior sobre threads e é baseada em biblioteca; portanto, não vejo razão para que algo semelhante não possa ser construído em C ++, pois o TPL já é baseado em thread e não depende de recursos especiais no padrão de linguagem para sua implementação (embora as palavras-chave asynce awaittenham sido adicionadas ao compilador C # para facilitar essa programação).

Uma tarefa na estrutura ecológica da Microsoft é mais ou menos equivalente a um futuro ou uma promessa . Basicamente, é uma função sem bloqueio (assíncrona); você o chama, ele retorna o controle de volta enquanto é executado em um novo encadeamento e, em seguida, você recupera o valor de retorno posteriormente, quando estiver disponível.

O TPL possui outros recursos Parallel.For, como o que permite processar um loop simultaneamente, usando vários threads. Todas essas coisas podem ser implementadas em C ++ como funções de biblioteca. De fato, essa biblioteca já foi escrita .

Tanto quanto eu sei, o PPL (Parallel Patterns Library para Microsoft C ++) não depende de nenhum recurso especial de linguagem.

— Robert Harvey
fonte

Uma distinção importante entre a Taske a Threadé que uma tarefa não representa necessariamente uma função sendo executada em outro encadeamento. Representa qualquer coisa que possa terminar ou gerar um valor enquanto não estiver sendo executado no encadeamento atual. Pode ser o resultado de nenhum encadeamento em execução, se não estiver representando o trabalho vinculado à CPU. Provavelmente o exemplo mais comum é o IO assíncrono. Não está representando quando uma função termina em outro thread; representa quando um gancho de SO específico é acionado. Taskpermite que você não se importe com a conclusão e o trate como "qualquer operação assíncrona".

— Servy

Eu realmente não posso mostrar um bom exemplo em um comentário ... grr. Vou ver se eu posso encontrar uma velha questão da mina ...

— Servy

@ Servy: Certo; a conclusão de uma operação assíncrona pode ser o resultado de um retorno de chamada de método em resposta a algum evento externo.

— Robert Harvey

Sim, esse é um exemplo. Geralmente é fácil configurar algo usando a TaskCompletionSource. A idéia é que você crie uma tarefa e continue executando, e esse encadeamento eventualmente faz algo que acaba configurando o resultado do TCS, concluindo assim a tarefa sem exigir que mais de um encadeamento seja executado.

— Servy

Há bibliotecas de threads por blocos há séculos no cpp. Existem os Thread Building Blocks da Intel que são muito bons e existem coisas semelhantes, como o OpenMP, que permite abstrair a segmentação de uma maneira do tipo 'deixe o sistema fazer isso por você' (isso é suportado pelo VC ++, você deve definir o / sinalizador openmp nas suas compilações)

A Microsoft também está trabalhando no Casablanca , que pode não ser uma biblioteca de tarefas verdadeiramente genérica, mas é uma estrutura para escrever sistemas baseados em tarefas (principalmente para fins de aplicativos da web) usando algo semelhante ao modelo de ator de Erlang

— gbjbaanb
fonte