Piadas à parte, para mim o humor do texto ainda pode ser aproveitado por aqueles que já se acham muito bons e acreditam não terem mais como crescer profissionalmente. Quando meu ego infla demais, ainda me lembro que enquanto programo com APIs de brincadeirinha e um sistema operacional que é uma piada tem gente projetando uma nave que vai sair da órbita do Sistema Solar!

Por outro lado, muitas pessoas recém-saídas da faculdade de computação ainda acham programação uma matéria difícil. Esse texto nos lembra que difícil era a vida 20, 40, 70 anos atrás, quando engenheiros e programadores eram a mesma pessoa, e quando se você não soubesse o que estava fazendo colocaria projetos de milhões em risco.

Por consequência, o programador de verdade vive no passado. E ele sempre se valoriza frente ao povão jovem, porque ele sabe resolver aquele problema de tela azul que mais ninguém sabe. E como eu costumo dizer, parafraseando uma figura ilustre da televisão brasileira, quem tem medo de abrir o Visual Studio e em vez disso fica projetando eternamente o software não vai muito longe: "quem sabe faz na hora!".

Aqui segue um breve resumo do texto original adaptado para os tempos atuais e com a minha visão preconceituosa de pensar sobre o assunto. Se quiser, use sua parte politicamente correta da mente e critique à vontade!

Linguagens. Lembre-se: inventar que você precisa de mais linguagens/recursos para fazer seu trabalho é lembrar que você é incompetente o suficiente para inventar esse tipo de desculpinha. Você é daqueles que diz "cada problema tem sua ferramenta específica" ou algo do tipo. Ou seja, um programador politicamente correto e ineficiente. Não vê que tudo o que você precisa está na linguagem C. Se não estiver, então está no assembly. Se não estiver nem no C nem no assembly não vale a pena ser pensado a respeito.

Programação Estruturada. É o primeiro e último paradigma a ser aplicado. Afinal de contas, Orientação a Objetos é mais uma desculpinha para não programar. São abstrações e mais abstrações para inventar que, uma vez que você é um peso morto que não consegue resolver um problema com funções e variáveis, precisa de classes, herança, templates e outras tranqueiras que vão transformar seu código simples e reto em uma cornucópia mágica que só vai impressionar os outros pela inutilidade e complexidade da solução!

Estrutura de dados. Outro ótimo conceito para enganar a si mesmo. Hoje são muitos os que se escravizam nos leiautes SQL e classes estranhas de frameworks estranhos que fazem todo o trabalho. Todos sabemos que a única estrutura realmente útil de saber é o array. O resto são variantes do mesmo tema: filas e pilhas.

Sistema operacional. Mac e Windows são brinquedinhos e Linux é um vídeo-game que dá mais trabalho de configurar do que de jogar. O programador de verdade usa algo como mainframes ou qualquer outro sistema operacional beta, que são bem esquisitos de mexer e que podem fazer um verdadeiro estrago nas mãos de quem não tiver lido TODO o manual. E saber todos os bugs conhecidos e importantes do kernel e sua localização de cor na hora de bootar é vital.

Ferramentas. Se você depende de uma IDE que tem Code Completion e outros penduricalhos do tipo, ou depende de algum outro editor seu favorito com seus 17459 plugins instalados, então você não é um programador de verdade. um programador de verdade usa o que tiver à mão na hora que precisar, seja um notepad, um hexdump ou até mesmo alguns beeps. A ferramenta não é limite para quem sabe programar de verdade.

Depuração. Vai dizer que precisa do código-fonte para depurar? Então você não faz a mínima ideia do que o programa faz. Apenas algumas olhadas na call stack e nos registradores podem fazer um programador de verdade solucionar um bug que os comedores de torta não conseguiriam depois de analisar aqueles gráficos UML com caixinhas dentro e casos de uso por meses a fio.

O Trabalho de programadores de verdade com certeza não é fazer programinhas que acessam basezinhas de SQL com opção de consulta e cadastro. Nem são aqueles saitezinhos com PHP/Apache, scripts e mais scripts. Não, senhor. São programas que lidam com o Sistema Operacional de uma forma mais íntima (criptografia de HD, drivers de File System, serviços de comunicação crítica, etc), ou são programas que fazem algo de verdadeiramente útil (compiladores, o próprio sistema operacional). Ou tavez que mexam diretamente com hardware (microcontroladores complexos, robôs, naves, aparelhagem médica, etc).

A Diversão de todo programador de verdade é conversar com os amigos (sobre programação), ler alguma coisa (sobre programação) e assistir filmes inteligentes (sobre programação ou pessoas que fizeram algum tipo de desafio intelectual "na marra"). Existe algo mais divertido que isso?

E, por fim, em seu Habitat Natural, poderemos encontrar páginas de código assembly espalhadas em volta da mesa, um computador travado por uma depuração remota de kernel por cabo serial, algumas anotações em hexa em um pedaço de papel, algumas dezenas de páginas abertas no navegador sobre comportamento das funções BIOS em HDs SATA com mais de 500 GB trabalhando em RAID4, café, salgadinhos, manchas no carpete. Quando não há nada para fazer, o ambiente está arrumadíssimo e não se nota a presença de programadores de verdade à vista.

E o Futuro do programador de verdade? Bom, a linguagem C pode até estar morrendo. Mas, e daí? Essa tal de C++ ainda suporta ponteiros. O resto das abstrações afeminadas como classes e herança podem ser totalmente ignoradas. O básico sempre existirá. Esqueça as versões com herança múltipla e o enigmático concepts. Seja homem!

O fato é que, independente de quanto mais o mundo se tornar "gerenciado" por trás de frameworks e programadores que preferem "fazer projetos" atrás de seus pacotes de escritório e casos de uso, quando algum problema pipocar, algum bug tenebroso ameaçar a vida útil de um projeto, um programador de verdade estará lá para salvar o dia, pois só um programador de verdade sabe fazer o seu trabalho. E bem feito.

PS: Na verdade, me lembrei. Eu peguei esse cacoete de falar "quem sabe faz na hora" do meu amigo Thiago. Ele também dizia "se vira nos 30!". Bom, se eu citar todas as frases brilhantes que ele usava quando trabalhávamos juntos o texto vai ficar bem longo =)

Compilação automática geralmente está disponível nas ferramentas de desenvolvimento. Se você estiver usando o Visual Studio, por exemplo, é possível fazer isso com uma linha:

devenv minha-solução.sln /Rebuild Release

Se não for exatamente o que você precisa, basta fazer uma pesquisa de quinze minutos e encontrar os parâmetros corretos. O objetivo é: eu rodo esse comando em cima do projeto inteiro em uma máquina zerada e ele simplesmente compila.

Múltiplas soluções

É lógico que ter apenas um solution/workspace para guardar projetos médios e grandes é inviável. Demora para carregar no ambiente e possuem dezenas de dependências. Isso já foi tentado duas vezes nas duas empresas em que trabalhei e não funcionou. Talvez por isso seja necessário criar um script que rode o comando acima para todas as soluções do projeto, o que não muda muito o modus operandi da coisa:

call :Build ..\Libraries\Libraries.sln
call :Build ..\Services\Services.sln
call :Build ..\Drivers\Drivers.sln
call :Build ..\Tools\Tools.sln
goto :eof

:Build
echo %1...
devenv "%1" /Rebuild Release
exit /b %errorlevel%

Note que meu script usa a estrutura padronizada dos diretórios de um projeto, onde cada tipo de componente tem sua pasta e solução.

Aos poucos você pode ir colocando "frescurinhas" em seu build (executa Debug e Release, roda automatizado no servidor, faz testes unitários, incrementa o número da versão, ...), mas algumas premissas sempre se mantêm:

• Deve ser possível compilar o projeto inteiro em um passo
• Deve ser possível usar qualquer máquina de desenvolvimento para isso

Regras simples de ser seguidas se você usar sempre a máxima do KISS.

C++

• História
  • A linguagem BCPL
  • O código-objeto
  • A linguagem B
  • A "função" char
  • O primeiro printf da história
  • A linguagem C
  • A linguagem C++
  • As influências
• Conceitos
  • O conceito programa
  • O código-objeto
  • Processo de compilação
  • Declaração x definição
  • Tipos
  • Lvalue x Rvalue
  • A passagem por valor
  • Ponteiros
  • Estruturas e classes
  • Espaços de nomes
  • Polimorfismo estático
  • Herança
  • Polimorfismo dinâmico
  • Iteradores
  • Função-objeto
  • Templates
  • Algoritmos genéricos
  • Qualificadores (traits)
  • O conceito RAII
• Linguagem
  • O operador de subscrito
  • A proteção protected
  • Sizeof e strings literais
  • Uso de reflexão com typeid
  • Typeid e o polimorfismo
  • Ponteiros de método
  • Ponteiros de método e o this
  • Try-catch fora do corpo da função
  • Sobrecarga de operadores
• Biblioteca
  • Biblioteca C no Windows
  • Mobilidade da pilha com prinff
  • Erros comuns de iteradores
  • STL
  • Boost
• Dicas
  • Erros comuns de iniciantes
  • Ponteiro nulo em entrevistas
  • Nem todo ponteiro nulo é inválido
  • Decifrando código obscuro
  • Usando do-while para evitar erros de macro
  • Sobrecarga por tipo de retorno

Espero que isso me ajude a continuar completando as lacunas do saite. Se não der certo, pelo menos já sei o que fiz.

Sugestões?

Esse artigo é só para constar em minha lista de referência para o aprendizado de C, C++ e todas as outras coisas que vem depois. Se eu tivesse que escrever isso lá no início, provavelmente recomendaria mais linques de livros e saites em inglês. Hoje, felizmente, temos um conteúdo em pleno desenvolvimento em nossa blogosfera tupiniquim. E espero que continue assim!

C/C++

• Strings
• Strings e Números
• Os diversos tipos de casting
• Pointeiros e Referências
• Templates
• Smart Pointer - Introdução
• Auto Pointer (auto_ptr)
• Boost Shared Pointer, Weak Pointer e Scoped Pointer
• Boost Shared Array e Scoped Array
• Quando usar cada um dos smart pointers
• As infinitas e riquíssimas discussões na lista C/C++

Visual Studio

• Como usar o Visual Studio
• Compilando o Boost no Windows (usando Visual Studio)

Mais assuntos?

A internet brasileira cresceu como um todo. Mesmo que você deseje saber mais sobre microprocessadores ou drivers para Windows, em português, hoje isso é possível. É claro que o que não é possível é você se dedicar profissionalmente a essas áreas sem saber inglês. Mas é uma muito bem-vinda manifestação das pessoas que fazem acontecer todas essas coisas em nosso país.

Também falei que iríamos resolver esse problema, afinal de contas, temos que salvar todos aqueles programas que usam dezenas de threads trabalhando ao mesmo tempo para contar números de um até dez.

A boa notícia é que o salvamento é mais simples do que parece: coloque todas as suas threads em uma sala trancada e deixe apenas uma chave. As threads terão que brigar para sair da sala e, depois que a vencedora sair, as outras terão que ficar esperando ela voltar.

Confuso? Se estiver, ainda bem. Isso quer dizer que estamos novamente em um daqueles artigos com "pseudo-parábolas", a maneira mais ilustrada de explicar as coisas.

A chave

Os SOs modernos possuem inúmeras maneiras de controlar e monitorar o acesso a recursos do sistema. Neste breve artigo irei falar apenas de um: o critical section, ou, em tradução livre, "seção crítica". O "seção" desse nome diz respeito a uma seção do programa, ou seja, um pedaço de código mesmo. Um pedaço de código crítico.

Resumidamente, um critical section é um recurso que apenas uma thread por vez pode obter. Para que outra thread tenha acesso ao mesmo critical section, a primeira thread que o obteve deve soltá-lo. Enquanto ela não solta, as outras threads ficam paradas, esperando pela chave, na sala trancada.

Do ponto de vista do programador, o critical secton é apenas uma estrutura que é usada na chamada de quatro funções básicas: para inicializar o recurso, para entrar na seção crítica, para sair da seção crítica e para liberar o recurso (quando aquele critical section não mais será usado).

Falando assim, parece simples. Bom, na verdade é simples, mesmo. Tudo que você precisa para corrigir o programa do artigo anterior é criar um critical section e fazer com que as threads obtenham-no antes de mexer com o contador compartilhado.

#include <windows.h>
#include <stdio.h>
 
#define MAX_GLOBAL_COUNTER 10
 
int g_globalCounter = 0;
CRITICAL_SECTION g_globalCounterCS;
 
 
DWORD WINAPI IncrementGlobalCounter(PVOID)
{
	DWORD tid = GetCurrentThreadId();
 
	while( g_globalCounter < MAX_GLOBAL_COUNTER )
	{
		// esse é o começo de nossa seção crítica
		// só uma thread entra por vez por aqui
		EnterCriticalSection(&g_globalCounterCS);
 
		int temp = g_globalCounter;
		temp = temp + 1;
		Sleep(0); // vou para o final da fila antes de contar
		g_globalCounter = temp;
 
		// esse é o fim de nossa seção crítica
		// a partir dessa chamada outra thread pode entrar pelo começo
		LeaveCriticalSection(&g_globalCounterCS);
 
		printf("Counter: %d\t\tThread: %d\n", temp, tid);
	}
	return 0;
}
 
 
int main()
{
	HANDLE threads[3];
	DWORD tids[3];
 
	// precisamos inicializar nosso recurso de seção crítica	
	InitializeCriticalSection(&g_globalCounterCS);
 
	for( int i = 0; i < 3; ++i )
	{
		threads[i] = CreateThread(NULL, 0, IncrementGlobalCounter, 0, 0, &tids[i]);
		printf("Thread %i: %d\n", i, tids[i]);
	}
 
	WaitForMultipleObjects(3, threads, TRUE, INFINITE);
 
	// precisamos liberar o recurso de seção crítica
	DeleteCriticalSection(&g_globalCounterCS);
}
 

Molho de chaves

Para finalizar, algo para pensar: se uma thread só consegue um critical section depois que outra thread soltá-lo, o que acontece se essa outra thread estiver esperando por outro critical section que uma thread que aguarda estiver segurando?

Acabamos de ilustrar um procedimento muito simples para cagar completamente no código e gerar um travamento que pode demorar de horas a semanas para ser detectado e resolvido. É o conhecido deadlock. Se você não entendeu ainda, imagine que, para voltar à sala das threads, a primeira thread que saiu precisa de duas chaves; só que ela só pegou a primeira, e a segunda está dentro da sala. Para pegar a segunda chave, ela precisa entrar na sala, só que a sala está trancada pelas duas chaves!

Deadlocks são sempre indesejáveis, e é por isso que existem diversas técnicas para tentar evitá-los. A mais conhecida é sempre obter os critical sections na mesma ordem. Dessa forma a obtenção de recursos é hierarquizada, o que impede que dois CSs estejam no mesmo nível de obtenção, evitando que duas threads distintas os obtenham.

Espero que tenha ficado claro nossa breve explanação de como podemos controlar programas multithreading. Espero, pois a próxima tarefa é entender outros conceitos mais abstratos e virtuais, como funções virtuais e classes abstratas.

Então eis que surge na porta do templo sagrado (a sala de desenvolvimento) um dos mortais que costuma acreditar que "dirige" seus funcionários. Vira-se para mim e "define" que esse projeto não poderá passar desse mês. E todas aquelas tarefas urgentes que estavam furando a fila de prioridades, como a última da semana passada, devem ser postergadas. É lógico que nada disso foi surpresa, visto que outros discursos desse tipo e outras tarefas urgentes já haviam aparecido no decorrer desses seis meses; mas, enfim, esse foi o primeiro deadline oficialmente definido.

Por isso mesmo, com uma preocupação constante em minha cabeça, decido desestressar um pouco e ter um almoço bem alargado (quatro horas) em um outro bairro, em outro ambiente, com uns velhos amigos para jogar alguma conversa fora. Nada como a vida fluindo devagar para fazer esquecer detalhes menos essenciais, como trabalho e estresse no trabalho. Sou obrigado nessa hora a parafrasear o sócio mais espirituoso de nossa empresa, que coincidentemente estava presente no almoço: "mas, afinal de contas, quem foi que definiu que a vida tem que ter trabalho e estresse?".

Eu assino embaixo.

Porém, terminado o almoço, volto a pensar em como resolverei o impasse do cronograma do tal projeto superimportante, quando, ao passar pela entrada do metrô, colocam na minha mão justamente um desses panfletos de rua com mensagens subliminares. E nele estava, acreditem, leitores, a solução para todos os meus problemas!

Se você está com algum PROBLEMA DE DIFÍCIL SOLUÇÃO e precisa de AJUDA URGENTE, peça esta ajuda a Santo Expedito que é o Santo dos Negócios que precisam de Pronta Solução e cuja invocação nunca é tardia. (Abaixo segue a oração ao Santo).

Agradeço a Santo Expedito pela Graça Alcançada

É lógico que toda essa história fantasiosa pode ser pura ficção com um pingo sequer de realidade, e no fundo almocei foi mesmo é com meus amigos imaginários. No entanto, é capaz que esse não seja um cenário incomum em muitas empresas de tecnologia por aí afora, que insistem em fazer duas coisas que, aliadas, podem gerar qualquer coisa, menos um projeto bem feito e testado:

- Pedir que seus funcionários elaborem um cronograma de um projeto complexo (um mês ou mais de trabalho).
- Pedir que seus funcionários espremam o tempo definido para o projeto de alguma forma mágica.

O problema é que, na área de informática, apesar de ciência esotérica e cheia de mistérios, não existem santos, não existem milagres e não existe mágica que gere um código de qualidade se não for despendido para ele uma soma considerável de tempo e trabalho. E não estou falando de nenhum luxo. É o tempo justo, mesmo.

Por isso que há eras meu amigo Strauss e o conhecido Joel falam sobre as necessidades básicas de um programador e criticam o resto. As necessidades básicas, na minha opinião, se resumem em três regras de ouro:

1. Dê condições para o programador pensar
2. Dê condições para o programador trabalhar
3. Dê condições para o programador programar

Fora isso, o resto é perfumaria, perda de tempo e enchimento de saco. Os bons programadores não querem ser gerenciados: querem programar. Só isso. Deixe-os com seus problemas e vá tomar conta de algo que não atrapalhe suas vidas. Já estará fazendo um imenso avanço na produtividade de sua empresa.

Um ambiente complexo como esse é repleto de pequenos detalhes que podem fazer o iniciante logo desanimar quando tentar depurar um programa com mais de uma thread. De fato, eu já percebi que muitos não vão saber nem como começar a mastigar o problema.

Por isso mesmo que eu tive que inventar algumas analogias no mínimo interessantes a respeito do assunto. Sem analogias, não sei como falaria sobre essas coisas de forma amena e "explicável".

A primeira "parábola" conta a história da fila das threads em direção ao guichê das CPUs.

O exemplo abaixo cria três threads, todas iniciando na mesma função. O objetivo de todas elas é incrementar um contador até que seu valor chegue a 10. Todas param quando esse objetivo é alcançado.

#include <windows.h>
#include <stdio.h>
 
#define MAX_GLOBAL_COUNTER 10
 
int g_globalCounter = 0;
 
 
DWORD WINAPI IncrementGlobalCounter(PVOID)
{
	DWORD tid = GetCurrentThreadId();
 
	while( g_globalCounter < MAX_GLOBAL_COUNTER )
	{
		int temp = g_globalCounter;
		temp = temp + 1;
		g_globalCounter = temp;
		printf("Counter: %d\t\tThread: %d\n", temp, tid);
	}
	return 0;
}
 
 
int main()
{
	HANDLE threads[3];
	DWORD tids[3];
 
	for( int i = 0; i < 3; ++i )
	{
		threads[i] = CreateThread(NULL, 0, IncrementGlobalCounter, 0, 0, &tids[i]);
		printf("Thread %i: %d\n", i, tids[i]);
	}
 
	WaitForMultipleObjects(3, threads, TRUE, INFINITE);
}

Esta é a saída:

Thread 0: 3508
Thread 1: 1744
Thread 2: 3128
Counter: 1              Thread: 3508
Counter: 2              Thread: 3508
Counter: 3              Thread: 3508
Counter: 4              Thread: 3508
Counter: 5              Thread: 3508
Counter: 6              Thread: 3508
Counter: 7              Thread: 3508
Counter: 8              Thread: 3508
Counter: 9              Thread: 3508
Counter: 10             Thread: 3508

Pelo jeito, a primeira thread não deu chance para as outras. Isso acontece por causa do pequeno espaço de tempo que é necessário para realizar a tarefa de incrementar uma variável. Tempo esse tão pequeno que nem foi suficiente para a primeira thread dar lugar para as outras duas threads e ir para o final da fila.

A fila das threads

Quando uma thread quer realizar algum processamento, ela precisa entrar na fila das threads ativas, que aguardam pela CPU que irá atendê-las. Nessa fila ela pega uma senha e aguarda a sua vez. Só que cada um que é atendido pela CPU tem um tempo máximo de atendimento, que nós chamamos de quantum, ou time slice. Se o tempo máximo estoura, ou a thread não tem mais nada pra fazer, ela sai do guichê de atendimento e volta a ficar inativa, ou volta para o final da fila, aguardando por mais processamento.

Uma thread pode opcionalmente ir para o final da fila por conta própria. Para isso, basta que ela chame a função Sleep da API passando qualquer valor em milissegundos; até mesmo zero. Se passar um valor diferente de zero, ela irá para outra fila de espera, a fila das inativas, até o tempo determinado estourar. Depois ela volta para a fila das threads ativas. Se passar zero, ela vai direto para a fila das ativas.

#include <windows.h>
#include <stdio.h>
 
#define MAX_GLOBAL_COUNTER 10
 
int g_globalCounter = 0;
 
 
DWORD WINAPI IncrementGlobalCounter(PVOID)
{
	DWORD tid = GetCurrentThreadId();
 
	while( g_globalCounter < MAX_GLOBAL_COUNTER )
	{
		int temp = g_globalCounter;
		temp = temp + 1;
		g_globalCounter = temp;
		printf("Counter: %d\t\tThread: %d\n", temp, tid);
		Sleep(0); // vou para o final da fila
	}
	return 0;
}
 
 
int main()
{
	HANDLE threads[3];
	DWORD tids[3];
 
	for( int i = 0; i < 3; ++i )
	{
		threads[i] = CreateThread(NULL, 0, IncrementGlobalCounter, 0, 0, &tids[i]);
		printf("Thread %i: %d\n", i, tids[i]);
	}
 
	WaitForMultipleObjects(3, threads, TRUE, INFINITE);
}

Thread 0: 2284
Thread 1: 4080
Thread 2: 3572
Counter: 1              Thread: 2284
Counter: 2              Thread: 4080
Counter: 3              Thread: 3572
Counter: 4              Thread: 2284
Counter: 5              Thread: 4080
Counter: 6              Thread: 3572
Counter: 7              Thread: 2284
Counter: 8              Thread: 4080
Counter: 9              Thread: 3572
Counter: 10             Thread: 2284

Agora cada thread, depois de incrementar uma vez o contador, volta para o final da fila. Dessa forma vemos uma thread de cada vez incrementando o mesmo contador.

No próximo capítulo: problemas de sincronismo

Peraí. O mesmo contador? Isso não pode gerar problemas de duas threads tentando incrementar o mesmo contador ao mesmo tempo?

Não vou mentir; pode sim. Para isso acontecer, basta irmos para o final da fila antes de incrementarmos, mas após pegarmos o valor atual do contador. Note que a saída muda completamente.

#include <windows.h>
#include <stdio.h>
 
#define MAX_GLOBAL_COUNTER 10
 
int g_globalCounter = 0;
 
 
DWORD WINAPI IncrementGlobalCounter(PVOID)
{
	DWORD tid = GetCurrentThreadId();
 
	while( g_globalCounter < MAX_GLOBAL_COUNTER )
	{
		int temp = g_globalCounter;
		temp = temp + 1;
		Sleep(0); // vou para o final da fila antes de contar
		g_globalCounter = temp;
		printf("Counter: %d\t\tThread: %d\n", temp, tid);
	}
	return 0;
}
 
 
int main()
{
	HANDLE threads[3];
	DWORD tids[3];
 
	for( int i = 0; i < 3; ++i )
	{
		threads[i] = CreateThread(NULL, 0, IncrementGlobalCounter, 0, 0, &tids[i]);
		printf("Thread %i: %d\n", i, tids[i]);
	}
 
	WaitForMultipleObjects(3, threads, TRUE, INFINITE);
}

Thread 0: 2136
Thread 1: 4024
Thread 2: 2584
Counter: 1              Thread: 2136
Counter: 1              Thread: 4024
Counter: 1              Thread: 2584
Counter: 2              Thread: 2136
Counter: 2              Thread: 4024
Counter: 2              Thread: 2584
Counter: 3              Thread: 2136
Counter: 3              Thread: 4024
Counter: 3              Thread: 2584
Counter: 4              Thread: 2136
Counter: 4              Thread: 4024
Counter: 4              Thread: 2584
Counter: 5              Thread: 2136
Counter: 5              Thread: 4024
Counter: 5              Thread: 2584
Counter: 6              Thread: 2136
Counter: 6              Thread: 4024
Counter: 6              Thread: 2584
Counter: 7              Thread: 2136
Counter: 7              Thread: 4024
Counter: 7              Thread: 2584
Counter: 8              Thread: 2136
Counter: 8              Thread: 4024
Counter: 8              Thread: 2584
Counter: 9              Thread: 2136
Counter: 9              Thread: 4024
Counter: 9              Thread: 2584
Counter: 10             Thread: 2136
Counter: 10             Thread: 4024

Esse problema ocorre pelo seguinte motivo: quando uma thread guarda o valor do contador na variável temp e volta para o final da fila, ela deixa de armazenar o contador atualizado para apenas depois que todas as outras threads passarem na sua frente. Só que as outras threads também pegam o mesmo valor do contador, pois ele ainda não foi alterado. Quando chega a hora da segunda passada no guichê das CPUs, todas as threads incrementaram o mesmo valor do contador.

O exemplo acima forçou essa situação, mas é preciso lembrar que isso pode acontecer mesmo sem o Sleep. É possível que o tempo da thread se esgote e ela pare de ser atendida  justo na hora que iria salvar a variável temp no contador global. Dessa forma, ela vai para o final da fila à força e, quando voltar a ser atendida, uma outra thread já terá incrementado o mesmo valor.

Esse problema pode ser facilmente resolvido se utilizarmos um sistema de bloqueio entre threads do mesmo processo. Uma outra história para contar da próxima vez.

No cenário em que isso se passa não existem usuários logados no momento, o que significa a impossibilidade de rodar qualquer programa em uma sessão prévia e mantê-lo no ar após o logoff. A não ser que se trate de um serviço.

O nosso programa é justamente um serviço, e por isso ele continua rodando até o final, ou bem perto dele. A primeira ideia que vem à mente é instalar o Msvcmon - depurador remoto do Visual Studio - como um serviço, como aliás já foi demonstrado neste blogue.

Essa é uma boa ideia, de fato. Contudo, não podemos esquecer que a ordem de descarregamento dos serviços pode não favorecer o nosso depurador remoto e ele ir embora antes que consigamos "atachar" nosso VC no programa faltoso. Além do mais, a própria rede, que é disponibilizada com a ajuda de serviços, pode não estar no ar, mesmo que o Msvcmon esteja.

Tudo bem, vamos dizer que você é um expert em configuração de dependências de serviços e conseguiu fazer com que a rede, o Msvcmon e o programa faltoso sejam os últimos serviços - com exceção dos drivers - a serem descarregados. Bravo!

Contudo, isso não vai adiantar de muita coisa se for necessário parar a execução por um breve momento e analisar a pilha por, digamos,  cinco segundos. Esse é o tempo que o sistema - que continua rodando - precisa para desligar a máquina.

Agora o problema é outro: não há tempo para análise durante a depuração, pois o sistema continua rodando. Nesse caso, teremos que ser mais radicais e parar o próprio sistema para que possamos depurar calmamente o problema. Isso implica em termos que utilizar um depurador de kernel (WinDbg), pois só ele tem poderes de congelar o sistema inteiro.

Mas, ainda assim, precisamos de um depurador de user para fazer análises mais profundas ou, pelo menos, mais simples, com a ajuda de símbolos e tudo mais. Nesse caso é necessário usar um depurador de user que redireciona o controle para o depurador de kernel. A transição user mode >> kernel mode pode ser feita com apenas algumas configurações antes do reboot.

E, após toda essa bagunça, podemos depurar, no conforto de uma VM, o bendito programa matador.

.

A consequência interessante disso é que, uma vez que a prova de conceito deva ser um miniprojeto das principais partes de um software, desenvolvê-la significa programar todas as partes que realmente importam, ou seja, centrais para o funcionamento.

.

Portanto, conclui-se que desenvolver provas de conceito é a coisa mais divertida do Universo.

Para que servem

Além de serem extremamente divertidas e disputadas entre os programadores, desenvolver provas de conceito gera uma gama de vantagens para o desenvolvimento "sério" do software como um todo, "rodável" e "vendável":

• Permite testar as ideias por trás do software antes de gastar todo o tempo desenvolvendo-o.
• Gera conhecimento para os programadores e para que outros produtos sejam desenvolvidos.
• Torna o desenvolvimento algo ainda mais divertido, pois tira a parte chata a respeito de comentar código, testar código, mensurar código, rever código, etc.
• Consegue tornar o milagre do cronograma realista mais perto do provável.

Apenas essas vantagens já praticamente obrigam o profissional do software a pensar em produtos novos em termos de como pode-se testar tudo o que se está dizendo antes de realmente começar a trabalhar pra valer.

Como fazer

Mas antes que se pense que fazer provas de conceito não requer nenhuma responsabilidade e que o que você quer ser quando crescer é desenvolvedor de prova de conceito, é necessário colocar alguns pingos nos is antes de continuar. Para criar provas de conceito realmente agregadoras para o projeto, deve-se sempre:

• Dividir o software em seus componentes tecnológicos mais críticos e vitais para o sucesso da solução.
• Proteger as provas de conceito contra qualquer tipo de preconceito a respeito da tecnologia em questão: pese somente os fatos!
• Conhecer as limitações do software antes mesmo de provar seu funcionamento (por exemplo, não vai funcionar no Windows NT nem a pau).
• Garantir que esse conhecimento seja sempre compartilhado entre todos do desenvolvimento, pois trata-se de um projeto vazio que formará talvez as bases de um novo produto; se todos conhecerem as bases primeiro, ficará muito mais fácil todos tomarem conta.

Por último, deve-se pensar sempre em todos os programadores da equipe desenvolvendo provas de conceito. Um doce tão gostoso não pode ser privilégio apenas dos veteranos ou dos acadêmicos chatos, pois torna a vida dos "corregedores" de bugs chata e enfadonha. E error prone.

Por isso, desde a estagiária até o mocinho bicentenário merecem mexer em código fresco pelo menos uma vez a cada ciclo de desenvolvimento, que terminará com uma versão nova cheia de melhorias que foram testadas em suas respectivas provas de conceito. Provas de conceito que todos tiveram a honra de brincar um pouquinho.