"Processi, threads e trame"

Per gentile concessione della Redazione di FoxPress
Traduzione di Giancarlo Piccinato


 

Cos'è un Thread? Cos'è un Processo?

Un Processo è qualcosa che ci risulta familiare. Se lanci Microsoft Word ® e VFP, allora otteniamo due processi separati che stanno correndo allo stesso tempo nonostante si sia in presenza di una sola CPU.

Il sistema operativo assegna il tempo a ciascuno dei processi e passa dall'uno all'altro secondo la necessità.

In un sistema multitasking non-preemptive (il task [compito] è sinonimo di processo) tale come Windows 3.1, un processo può fermare l'esecuzione di un altro processo, dato che il sistema operativo passa un messaggio a ciascuno dei processi per permettere la sua interpretazione; mentre un processo interpreta un messaggio, gli altri processi si fermano.

In un sistema multitasking preemptive, la CPU realizza una distribuzione del tempo di esecuzione che coinvolge le istruzioni di tutti i processi.

L'architettura di una applicazione basata in un unico processo non funziona bene in un server di applicazioni Web. Un utente con un Browser in Hawaii visita una pagina del tuo sito Web e il server inizia a processare la richiesta. Allo stesso tempo arriva un altro utente dalla Nuova Zelanda e deve aspettare fino a quando la richiesta anteriore non si sia conclusa.

Una possibile soluzione a questo problema è avere molteplici processi che rispondano a queste richieste in modo tale che siano soddisfatte in un modo più o meno simultaneo. Questo è ciò che fanno i CGI (ogni CGI crea un nuovo processo che a sua volta crea una pagina, dopodichè finisce). Tuttavia, ciò porta ad un uso eccessivo delle risorse ed è inefficiente.

Una migliore soluzione è avere molti threads (trame) all'interno di un unico processo capace di processare le richieste della Web. Ogni processo ha un thread principale, però può creare molti threads privati per uso proprio. Il sistema operativo non solo è perfettamente felice facendo ciò e saltando da un thread all'altro all'interno di uno stesso processo senonché assegna secondo le necessità uno spazio di memoria a ciascuno dei thread privati, migliorando considerevolmente l'uso delle risorse.

Per questa ragione i threads godono di molta efficienza. L'architettura ISAPI si basa in molteplici threads. Ogni hit nella web usa uno di un pool di threads per soddisfare le richieste.

Programmazione di molteplici Thread

Scrivere codice per molteplici threads è differente dallo scrivere un codice per un solo thread.

Immaginiamo che mentre una delle procedure sta eseguendosi, il processore salta ad un altro thread che deve eseguire la stessa procedura. Questo salto potrebbe prodursi in qualsiasi momento ed è molto difficile da provare.

Consideriamo il seguente pseudo-codice:

FUNCTION MyProc
*LOCAL myvar
Myvar = 44
If myvar = 44
  Myvar = 55
Endif
Return myvar

Con l'istruzione LOCAL commentata, quale sarà il valore di questa funzione in un ambiente multithread? Sembrerebbe che 55.
Tuttavia, potrebbe darsi che dopo aver assegnato il valore 44, un altro thread abrebbe potuto eseguirsi, cambiare il valore di myvar a 55 ed allora il thread iniziale processerebbe la condizione IF con myvar = 55.

Una soluzione a questo problema è l'usare l'istruzione LOCAL. Un'altra soluzione sarebbe quella di bloccare l'esecuzione di tutti gli altri threads con qualche tipo di tecnica di sincronizzazione. I programmi que eseguono molteplici threads deve utilizzare variabili private per ogni thread e zone critiche, semafori ed altri meccanismi per poter accedere in forma ordinata alle variabili globali del programma.

Thread ed oggetti COM

Cosa succede quando un thread crea una istanza di un server COM ed un altro thread necessita chiamare un metodo di quel server?
I servers single threaded sono il tipo di modello di Thread per oggetti COM più semplice.

Questo è l'unico modello disponibile usando Windows NT 3.5. ed è l'unico che sopporta VFP5 (VFP5 è stato rilasciato nell'agosto del 1996).

Sotto NT 3.5, se si avevano molteplici threads in un unico processo, non si poteva usare un oggetto COM. Un server COM usava lo stesso thread come cliente. Il cliente non poteva chiamare il server COM usando un thread differente. Ciò rendeva impossibile creare servers o clienti COM che fossero multi-threaded.

Con l'arrivo dell'NT3.51 e Win 95 i servers e i clienti COM multithreaded sono una realtà. Con il modello apartment (qualche volta chiamato Single Apartment Model) si potevano chiamare molteplici oggetti COM e tutti i threads di un processo possono usare questi oggetti COM.

Il modello Free-threaded o Multi-Threaded Apartment Model non sincronizza la comunicazione COM, e gli oggetti COM devono sincorinizzarsi tra di loro per proteggersi dai molteplici accessi. Questo modello di thread è disponibile a partire dal Win NT4 e Win 95 con DCOM 95.

Visual FoxPro ed il MultiThread Visual

FoxPro 5.0 è single threaded e perciò deve simulare il multithread. In VFP 6.0, invece, gli oggetti COM sono stati dotati con la possibilità di supportare il Thread Apartment Model y il Microsoft Transaction Server.

Sebbene VFP soddisfi le condizioni degli oggetti COM, sia Apartment Model Threaded COM che oggetti del MS Transaction Server, la concomitanza rimane un problema. Il problema sta nel modo in cui è fatto il runtime di VFP. Mentre è possibile caricare molteplici istanze di un oggetto nello stesso processo, non è possibile far sì che le istanze così create operino simultaneamente (problema che è stato risolto con il Service Pack 3, che dispone di una nuova versione del runtime).

Per esempio, se IIS carica due istanze di un oggetto dovuto a due accessi simultanei alla stessa pagina ASP, uno sarà eseguito dopo l'altro. Assumiamo che il Metodo1 esegue una consulta che dura 15 secondi mentre il Metodo2 ne esegue un'altra che dura 1 secondo. Se il Metodo1 viene invocato prima del Metodo2, allora il Metodo2 rimarrà bloccato per 15 secondi.

Con ciò si deduce che è estremamente difficile costruire aaplicazioni scalabili.

Nemmeno gli oggetti di VB sono multi-threaded; ciò che fanno è eseguire molteplici istanze allo stesso tempo. Questo, in realtà, è un trucco poiché ogni oggetto ottiene la sua copia del runtime simulando, così, un ambiente multi-threaded senza esserlo.
Multi-thread implica una ri-entrata del codice: lo stesso blocco di codice corre simultaneamente. ... VB e VFP emulano il thread caricando in memoria molteplici aree con Thread Local Storage proprio.

La difficoltá principale in VFP è che esistono molte variabili globali che non possono essere isolate facilmente e metterle in un "magazzino" locale per ogni oggetto creato. Le variabili globali verrebbero ad essere le variabili d'ambiente quali i comandi SET che regolano il funzionamento di VFP.

Vale la pena ricordare che i servers DLL (InProc) non sono più rapidi dei servers EXE (OutOfProc) - l'apparente rapidità del DLL è dovuta all'assenza di chiamate all'interfaccia grafica.
Per capirci meglio: il codice corre alla stessa velocità - soltanto quando si passano parametri il processo si rallenta un po', e ancor più con i servers OutOfProc (qualcosa come 500-1000 volte più lento) sotto condizioni ideali. Il fatto è che se abbiamo un procedimento che esegue una consulta che impiega 20 secondi a rispondere, la differenza tra i due tipi di servers non saranno notabili. Però, se abbiamo una routine che chiama il server VFP in un piccolo loop che deve estrarre un piccolo gruppo di dati, ci renderemo conto che la differenza è come dalla notte al giorno.

L'Apartment Model Threading permette caricare molteplici componenti del tipo InProcess (DLL) in forma simultanea. Visual FoxPro® può maneggiare molteplici e simultanei 'apartments' threads di un oggetto in memoria in forma simultanea (uno per ogni cliente attivo). Il modello "apartment" garantisce che le chiamate saranno realizzate sempre dallo stesso thread creato e con ciò si garantisce la sicurezza per eseguire le applicazioni.

La conversione di uno strumento talmente complesso come VFP perché possa essere integrata in un modello di threads no è un compito triviale. ... Con Visual FoxPro 6.0® Service Pack 3 appare una nuova versione della libreria runtime che supporta l'esecuzione simultanea di metodi. Questa versione è stata rilasciata in maggio e si può scaricare da http://msdn.microsoft.com/vstudio/sp/default.asp.

Riassumendo, ciò che davvero è importante:

    1. - I componenti ActiveX creati come EXE (con qualsiasi versione di Visual FoxPro) sono più lenti nel passaggio di parametri e non possonon essere eseguiti all'interno di MTS.
    2. - I componenti ActiveX creati come DLL con Visual FoxPro 5.0® non si possono utilizzare con MTS perché non sono compatibili con l'Apartment Model.
    3. - I componenti ActiveX creati come DLL con Visual FoxPro 6.0® possono essere impiegati con MTS però, internamente, interviene un bloccaggio da parte del runtime che impedisce l'esecuzione simultanea dei metodi di oggetti distinti.
    4. - I componenti ActiveX creati con Visual FoxPro 6.0 SP3 possono essere eseguiti sotto MTS ed in forma simultanea poichè esiste una versione speciale della libreria runtime.

     

    Copyright dell'articolo: FoxPress

    © FoxPro e Visual FoxPro sono un marchi registrati da Microsoft Corporation



data: 29/07/1999
webmaster@foxitaly.com