Classe d'arte (applicazione multi-thread)
Dal momento che non può esserci lezione senza un insegnante, è necessario un insegnante (thread principale). Quando arrivi in classe ti siedi e l'insegnante tiene conto di tutti e assegna alla classe di dipingere quadri per la giornata.
L'insegnante assegna a tutti gli studenti la giornata per iniziare a dipingere (inizializzazione e assegnazione del thread).
Poiché la scuola ha solo così tante vernici, tutti dovranno condividere i colori tra loro (le vernici rappresentano la memoria).
Diciamo che stai dipingendo un drago e vuoi dargli occhi rossi folli ma qualcun altro sta usando la vernice rossa. Non puoi semplicemente andare oltre e prendere la vernice per te perché allora nessun altro sarebbe in grado di usarla. Invece, ciò che fai è educatamente chiedere di condividere (blocco delle risorse) la vernice. Ne usi un po ', poi lo passi. Potrebbe essere necessario attendere un po 'per riaverlo, ma consente a tutti coloro che ne hanno bisogno di ottenerne un po' senza combattere con la vernice (condizioni di gara).
Alla fine della lezione l'insegnante termina la lezione (iscrizione a thread).
Gioco (applicazione multi-processo)
Giocare a carte con gli amici (o gioco equivalente con oggetti da collezione):
Diciamo che ti ritrovi con i tuoi amici (processi) dopo la scuola. Non ci sono insegnanti intorno a nessuno è lì per dirti cosa fare.
Tutti si riuniscono per giocare (applicazioni multi-processo o multi-layer).
Pensi intensamente a come puoi usare le tue carte per battere i tuoi avversari (elaborazione interna) e provi a condividere idee con il tuo partner quando ti viene in mente un'idea (messaggio che passa).
Se diventi davvero bravo puoi iscriverti a un club:
Leader (programma esecutivo) Membri (sottoprogrammi)
Se il club diventa davvero bravo, potrebbe trovare un modo speciale (API) per comunicare tra loro per aiutare a migliorare la strategia.
Ho scelto di non menzionare più processori / core qui perché l'astrazione diventa piuttosto complicata (e il cambio di contesto è ancora trasparente per la maggior parte delle applicazioni). Probabilmente potrei iniziare dicendo che ogni squadra nel gioco rappresenta un processore / core separato e la maggior parte dei giochi fa ancora schifo perché permettono solo a poche squadre di giocare insieme in una partita. Il futuro potrebbe assomigliare di più a un MMORPG in cui molte persone possono giocare insieme in una partita in squadre diverse.
Cercare di sviluppare una metafora per bambini per un sistema di elaborazione distributiva su molti computer core o molte reti host sarebbe piuttosto interessante con cui giocare, ma non è quello che Op ha richiesto.
Nota:
Il messaggio che passa sopra è un riferimento alle molte forme di comunicazione che i programmi usano per parlare tra loro. Come le persone, le applicazioni hanno molti modi per parlare tra loro. Scrivere è come eseguire il piping di dati serializzati, parlare è come fare rete, sussurrare è come fare rete su una connessione crittografata, i database sono come una score card (struttura finita con dati ben definiti) e usare MSMQ è come toccare il codice morse battendo la testa contro un superficie solida.
La maggior parte delle altre forme di comunicazione oltre quella confonde troppo per me per considerarle indistinguibili.
A parte:
Se hai mai giocato a un gioco online come Halo, le persone che si uniscono ai gruppi (o diventano giocatori professionisti) di solito hanno una lingua abbreviata per dare chiamate per indirizzare l'un l'altro dove sono i giocatori dell'altra squadra e cosa stanno usando. È davvero odioso se non conosci le chiamate ma è sorprendentemente efficace durante il gioco.
È interessante come, anche se la maggior parte delle persone che vivono in una determinata cultura parlano una lingua comune ma all'interno di quella cultura le persone sviluppano linguaggi di dominio brevi e brevi che sono ottimizzati per gestire compiti specifici. Nel calcolo lo confronterei con un'API.