Classe de arte (aplicação multithread)
Como não pode haver aula sem professor, você precisa de um professor (thread principal). Quando você chega à aula, senta-se e o professor é responsável por todos e designa a turma para pintar quadros para o dia.
O professor designa todos os alunos do dia para começar a pintar (inicialização e atribuição de linhas).
Como a escola tem apenas tantas tintas, todos terão que compartilhar cores entre si (tintas representam memória).
Digamos que você esteja pintando um dragão e queira dar olhos vermelhos loucos, mas outra pessoa está usando a tinta vermelha. Você não pode simplesmente passar a tinta para si, porque ninguém mais poderia usá-la. Em vez disso, o que você faz é pedir educadamente para compartilhar (bloqueio de recursos) a tinta. Você usa um pouco e depois passa adiante. Você pode ter que esperar um pouco para recuperá-lo, mas isso permite a todos que precisam dele um pouco sem lutar com pintura (condições da corrida).
No final da aula, o professor dispensa a aula (junção de linha).
Jogos (aplicação multiprocessos)
Jogando um jogo de cartas com amigos (ou jogo equivalente com itens colecionáveis):
Digamos que você se reúna com seus amigos (processos) depois da escola. Não há professores por perto, ninguém está lá para lhe dizer o que fazer.
Todos se reúnem para jogar (aplicativo com vários processos ou com várias camadas).
Você pensa muito sobre como pode usar seus cartões para derrotar seus oponentes (processamento interno) e tenta compartilhar idéias com seu parceiro quando tiver uma ideia (passagem de mensagens).
Se você for realmente bom, poderá ingressar em um clube:
Líder (programa executivo) Membros (subprogramas)
Se o clube ficar realmente bom, eles podem criar uma maneira especial (API) de se comunicar para ajudar a criar melhores estratégias.
Eu escolhi não mencionar vários processadores / núcleos aqui porque a abstração fica bastante complicada (e a alternância de contexto ainda é transparente para a maioria dos aplicativos). Provavelmente, eu poderia começar dizendo que cada equipe do jogo representa um processador / núcleo separado e a maioria dos jogos ainda é ruim porque eles permitem apenas que algumas equipes joguem juntas em um jogo. O futuro pode parecer algo mais como um MMORPG, onde muitas pessoas podem jogar juntas em um jogo em muitas equipes diferentes.
Tentar desenvolver uma metáfora infantil para um sistema de processamento distributivo em um computador com muitos núcleos ou em uma rede host seria bastante interessante, mas não foi isso que o Op pediu.
Nota:
A passagem de mensagens acima é uma referência às muitas formas de comunicação que os programas usam para conversar entre si. Como as pessoas, os aplicativos têm muitas maneiras de se comunicar. Escrever é como canalizar dados serializados, falar é como rede, sussurrar é como rede através de uma conexão criptografada, bancos de dados são como um cartão de pontuação (estrutura finita com dados bem definidos), e usar o MSMQ é como tocar no código morse, batendo sua cabeça contra um superfície sólida.
A maioria das outras formas de comunicação além dessas se confundem demais para eu considerá-las indistinguíveis.
A parte, de lado:
Se você já jogou um jogo online como o Halo, as pessoas que se juntam a grupos (ou se tornam jogadores profissionais) geralmente têm um idioma abreviado para fazer chamadas para direcionar umas às outras onde os jogadores da outra equipe estão e o que estão usando. É realmente desagradável se você não conhece as chamadas, mas é surpreendentemente eficaz durante o jogo.
É interessante como, embora a maioria das pessoas que vive em uma determinada cultura fale um idioma comum, mas nessa cultura as pessoas desenvolvam idiomas de domínio sucintos mais curtos, otimizados para lidar com tarefas específicas. Na computação, eu compararia isso a uma API.