Sistemi multicontrollori Master/Slave

La crescente domanda di prestazioni funzionali spinge i costruttori di apparecchiature elettroniche all’impiego di architetture multicontrollore. La gestione delle operazioni viene demandata a due o più microprocessori, rendendo possibile la multifunzionalità a un costo accessibile.

Introduzione

Alcuni termini come multimedialità, multitasking, coprocessing sono ormai entrati a far parte del nostro lessico quotidiano e nessuno si meraviglia più nell’osservare il realismo delle immagini 3D elaborate da una Playstation oppure nell’osservare la velocità e la definizione con cui filmati e pagine web vengono servite sul nostro PC o tablet. E quando le cose non avvengono alla massima velocità e perfezione siamo subito pronti a lamentarci per la cattiva qualità del prodotto. Tutto questo può apparire normale se ci si pone nei panni dell’utente che paga e vuole essere servito al meglio. Ma poniamoci per un attimo nei panni del costruttore e pensiamo a quali evoluzioni deve compiere per ottenere certe prestazioni a costi accessibili. Fino a qualche anno fa la gara era basata sulla velocità di calcolo dei microprocessori: 50 - 100 - 200 - 700 - 1.300 MHz rappresentano lo sviluppo della velocità di clock con cui le CPU dei nostri PC operano. Anche il numero di bit che rappresenta il “parallelismo macchina” è passato da 8 a 16 e da 32 a 64 bit. Il limite di questo processo è imposto da almeno due fattori:

1) il surriscaldamento della CPU;

2) il costo di tecnologie così sofisticate.

I primi coprocessori matematici comparsi negli anni Ottanta svolgevano solo alcune funzioni di calcolo ausiliarie e intervenivano quando l’applicazione lo richiedeva e lo giustificava. In seguito, per sfruttare appieno la potenzialità del multiprocessing, sono nate le CPU dual core le quali integrano nello stesso package due processori uguali che operano in comaking raddoppiando di fatto la potenza di calcolo a parità di velocità di clock. E ovviamente nello spazio di due socket si possono immaginare installate due architetture dual core, pervenendo quindi a un totale di quattro processori. Per sfruttare questa nuova potenzialità anche i programmi applicativi devono essere adeguati alle nuove architetture, a partire dal sistema operativo.

L’HARDWARE

L’organizzazione di una macchina multiprocessore dal punto di vista hardware può assumere varie configurazioni in dipendenza dell’applicazione prevista. L’approccio al problema cambia, infatti, se è richiesta potenza di calcolo oppure velocità di elaborazione oppure bisogna gestire grosse quantità di dati, etc. Si arriva così a strutture che possono lavorare sul medesimo bus, oppure a strutture che possono accedere alla memoria contemporaneamente (SMP) o a soluzioni che interagiscono con scambio di messaggi; strutture che utilizzano un proprio sistema operativo o strutture che operano in simultanea con collegamento a stella, o ancora ad anello, a griglia, etc. Ciascuna struttura presenta i propri vantaggi e svantaggi che vanno pertanto valutati attentamente in fase di scelta dell’architettura. In Figura 1 sono rappresentati tre diversi modelli di organizzazione di un sistema multiprocessore: a) condivisione di memoria; b) scambio di messaggi; c) struttura distribuita.

Figura 1: diversi modelli di organizzazione di un sistema multiprocessore: a) condivisione di memoria; b) scambio di messaggi; c) struttura distribuita.

Figura 1: diversi modelli di organizzazione di un sistema multiprocessore: a) condivisione di memoria; b) scambio di messaggi; c) struttura distribuita

SISTEMI A CONDIVISIONE DI MEMORIA SMP

In questa modalità, ampiamente diffusa e impiegata da parte di vari sistemi operativi come Windows, Linux, MacOS, Solaris, varie CPU condividono la stessa RAM (Shared Memory Multiprocessor, anche noto come Symmetric Multiprocessing), accedendo a essa attraverso il medesimo bus. Si comprende facilmente come un’architettura del genere trova il suo collo di bottiglia proprio nell’accesso al bus. Se, infatti, i microprocessori sono molti a contendersi il bus, la migliorata velocità di elaborazione verrà vanificata nell’attesa che il bus si renda disponibile. Per ovviare a ciò, è possibile ricorrere a una serie di espedienti: ad esempio, è possibile configurare alcune CPU per accessi privilegiati alla RAM (architettura NUMA, Non Uniform Memory Access) oppure dotare ciascuna CPU di una propria memoria cache nella quale effettuare la maggior parte del lavoro, riducendo così il numero di accessi alla memoria comune (Figura 2).

Figura 2: a) CPU configurata per accessi privilegiati alla RAM (architettura NUMA); b) CPU con propria memoria cache.

Figura 2: a) CPU configurata per accessi privilegiati alla RAM (architettura NUMA); b) CPU con propria memoria cache

SISTEMI A SCAMBIO DI MESSAGGI

Un altro possibile approccio al multiprocessing è rappresentato dalla struttura a scambio di messaggi. In questo caso i processori concorrenti sono dotati ciascuno della propria memoria e del proprio sistema operativo. Il risultato dell’elaborazione viene trasferito alla memoria o all’unità condivisa sotto il controllo del software attraverso reti di interconnessione. Il problema del contenzioso della risorsa condivisa si sposta sull’efficacia del protocollo di comunicazione. Un esempio rappresentativo di multiprocessing a scambio di messaggi può essere facilmente immaginato pensando le CPU collegate tramite Internet o in qualche modo su rete WAN/LAN, pervenendo così alla cosiddetta struttura distribuita. Dopo questi brevi cenni di organizzazione dei sistemi multiprocessore passiamo a occuparci di una categoria ben precisa di queste architetture, conosciuta come struttura Master/Slave. Tipicamente un sistema multiprocessore Master/Slave è costituito da una CPU principale denominata Master e una o più CPU di tipo Slave. Il Master riceve le chiamate dal sistema e ripartisce i compiti verso i processori Slave (Figura 3).

Figura 3: sistema multiprocessor e Master/Slave con CPU principale master e una o più CPU slave.

Figura 3: sistema multiprocessor e Master/Slave con CPU principale Master e una o più CPU Slave

Il processo avviene sempre sotto il controllo del Master il quale si preoccupa tra l’altro di non lasciare risorse inoperative e garantisce una ripartizione equilibrata dei carichi di lavoro in ogni istante. I vantaggi di un’organizzazione del genere sono molteplici: vi è un unico sistema operativo, vi è un’unica struttura dei dati e un unico bus, quindi non c’è bisogno di sincronizzazione tra le risorse, vi è un’unica cache e quindi si riduce il rischio di inconsistenza dei dati. Per contro, un’architettura come questa si presta bene fino a quando le CPU Slave non sono molte. Quando, infatti, il carico di lavoro diventa oneroso per la CPU Master, essa stessa diventa il collo di bottiglia del sistema e l’efficienza della struttura viene vanificata. Fortunatamente, problematiche di questo tipo, anche se affascinanti sotto il profilo teorico, ricadono nella sfera di competenza delle grandi case costruttrici impegnate a fronteggiarsi il mercato dei grandi elaboratori da calcolo, delle workstation per la gestione di server di rete e motori di ricerca.

Rimanendo nell’ambito delle applicazioni dei microprocessori, contesto a noi più familiare, possiamo guardare con uguale interesse alle scelte progettuali che ogni giorno ci poniamo nel disegnare una scheda a microprocessore. Il multiprocessing si applica ormai quotidianamente in una delle qualsiasi applicazioni dei microprocessori non appena ci poniamo il problema di interfacciare la porta USB o la porta Ethernet oppure un CAN bus. Viene spontaneo rinviare le funzioni di interfaccia con il mondo esterno a una CPU specializzata per questo o quel compito e, sempre più spesso, vediamo convivere sulla nostra applicazione 3, 4 o più microprocessori di cui uno Master, che sopravvede ai compiti del main program e gli altri Slave che si preoccupano di interfacciare la periferica, il bus, il campo, la comunicazione, etc. Ci capita quindi tutti i giorni di realizzare architetture multiprocessing quando utilizziamo, ad esempio, la porta SPI oppure il bus I2C per far dialogare tra loro due o più microprocessori. Del resto i costruttori di MCU offrono quasi sempre e del tutto gratis le API da implementare nel firmware per interfacciare senza grossi problemi un PC oppure il WEB oppure una rete LAN senza doverci preoccupare di conoscerne il protocollo ma curando semplicemente lo sviluppo del programma relativo alla nostra applicazione. I protocolli SPI ed I2Cbus ci consentono di poter dichiarare Master oppure Slave ciascuna unità di elaborazione e gestire le chiamate da e verso questa in funzione delle necessità operative. Pertanto un sistema multiprocessore basato sull’impiego di questi versatili bus di comunicazione è assimilabile a una struttura multiprocessing a scambio di messaggi, del tutto identica a quella trattata in apertura di questo articolo, valida per i grossi sistemi basati su processori AMD oppure INTEL.

Scarica subito una copia gratis

Una risposta

  1. luca.arsiero 22 Novembre 2020

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend