Operating System/2

Di seguito ho voluto introdurre una breve descrizione di OS/2, uno storico sistema operativo che fù sviluppato dalla IBM per l’uso sui propri personal computer.

L’inizio della storia di OS/2 risale al 1984, con l’arrivo sul mercato del primo PC AT IBM con processore 80286 che per la prima volta in un personal computer supportava la modalità protetta per il sistema operativo, una tecnica per avere un sistema stabile e al sicuro da crash o malfunzionamenti delle applicazioni.

Il progetto venne iniziato congiuntamente da IBM e da Microsoft ed in seguito sviluppato esclusivamente da IBM. Dotato di ottima stabilità, tecnicamente superiore alla concorrenza Microsoft ma meno diffuso per via della esosità di risorse di memoria delle prime versioni e storicamente carente di applicazioni, non riuscì mai a rimontare lo svantaggio presso gli utenti finali, nemmeno quando IBM con una mossa promozionale provò a distribuire gratis le versioni 3.0 e 4.0, molto migliorate. OS/2 si ricavò comunque una nicchia nel settore bancario, dove conserva ancora una certa base installata. Attualmente lo sviluppo di IBM OS/2 è congelato e il supporto tecnico a questo sistema operativo da parte della casa madre è cessato il 31 dicembre 2006 (salvo l’acquisto di un servizio di supporto personalizzato). La versione più aggiornata disponibile di OS/2 è del 2002, la versione 4.52 nota anche come OS/2 Convenience Pack 2 in cui vengono cumulati tutti i fixpack precedenti e che contiene in pratica una nuova versione di OS/2 Warp 4 e di OS/2 Warp Server for eBusiness (che supporta SMP fino a 64 processori con prestazioni ottimali a 8 processori).

Tuttavia IBM ha continuato ad aggiornare OS/2 negli anni, aggiungendo il supporto a tecnologie più recenti: Java 1.4, USB 2.0, Journaled File System (JFS) e le schede video NVidia, ATI e Matrox.

Oggi ai suoi clienti OS/2, IBM suggerisce di considerare GNU/Linux come sistema operativo alternativo.

Sysmmetric Multiprocessing

OS/2 usa il supporto SMP sysmmetric multiprocessing nel quale su ogni processore gira una copia identica del sistema operativo in maniera concorrenziale. Le copie comunicano tra loro secondo i bisogni. Il beneficio di questo modello è che molti processi girano simultaneamente (N processi per N CPU) aumentando notevolmente le prestazioni. Purtroppo può accadere che mentre una CPU è libera un’altra sia sovraccarica di lavoro causando inefficienza nel sistema. Ciò può essere evitato facendo condividere alcune strutture dati tra i processori. In questa maniera si permetterebbe ai processi e alle risorse (come la memoria) di essere condivisi dinamicamente tra i vari processori abbassando il dislivello del carico di lavoro tra di essi.

Scheduling

In OS/2 lo scheduling per processi con eguale priorità viene effettuato assegnando ad ogni processo un tempo di esecuzione pari a 31.25 millisecondi, dopo il quale, il processo in esecuzione viene prelazionato.

In un sistema ideale il tempo di prelazione è inferiore ai 25 microsecondi, tuttavia se il thread in esecuzione sta eseguendo una system call, tale tempo di prelazione può essere superiore.

Per evitare tempi di prelazione molto lunghi OS/2 prevede un ampio range di priorità e 14 stati con relative code (tutte doppiamene linkate tranne quella dello stato di esecuzione) che favoriscono una gestione efficiente dei threads dai vari stati di attesa fino all’esecuzione.

Utilizzando un’architettura SMP abbiamo per ogni processore una lista di stato di esecuzione, mentre le altre rimangono globali al sistema.

Personalmente ritengo che la politica di scheduling in OS/2 assomigli a quella dei sistemi soft real-time, infatti sono presenti system-call prelazionabili in punti strategici, differenziazione tra porzioni di codice (kernel-mode, interrupt-mode, user-mode) e implementazione dell’inversione di priorità.

Sincronizzazione

La gran parte del kernel di OS/2 è trattata come un’ampia sezione critica che può essere eseguita da un solo thread per volta all’interno del sistema. Questo per evitare che un thread del kernel che gira su una CPU sovrascriva una struttura dati condivisa con un altro thread del kernel che lavora su un’altra CPU.

Per l’accesso a delle sezioni critiche di codice viene utilizzato un semaforo chiamato spinlock. Il suo nome deriva dal lavoro ciclico di controllo (spin loop) che il processore esegue per controllare fino a quando la risorsa viene rilasciata.

Anche se apparentemente questo meccanismo di sincronizzazione può sembrare inconveniente, esso viene compensato dalla politica di scheduling e dalla logica di prelazione deterministica (deterministic pre-emption logic) che OS/2 adotta.

Frulla iPhone, Frulla!

Quanti di voi aspettano l’arrivo dell’iPhone nei negozi del nostro caro e vecchio continente? Quanti di voi vorrebbero averne uno? Quanti di voi sognano di poter sfruttare le sue potenzialità così lontane dai normali telefoni cellulari?

Ebbene mentre noi attendiamo desiderosamente, qualcuno oltreoceano, probabilmente già annoiato, ha ben pensato come divertirsi per l’ultima volta con il suo iPhone. Certo che gli statunitensi non smettono mai di impressionare per la loro enorme cultura e il loro irresistibile umorismo!

Esempio 1 – le prime tre regole

Mappatura tra tags Flex e classi AS

Uno degli aspetti più favolosi di Flex è la mappatura che esiste tra i tags MXML e le classi ActionScript. Il concetto è semplice anche se molto spesso ho trovato persone inesperte di Flex a cui era difficile spiegare come questo concetto lavorasse, e quanto esso fosse utile durante lo sviluppo di applicazioni RIA.

Se vi state avvicinando anche voi a Flex, qui di seguito troverete regole e relativi esempi che vi agevoleranno questa comprensione, rendendovi la vita molto più facile.

Prima Regola - Ogni tag MXML corrisponde ad una istanza di classe.

Seconda Regola - Tutti gli attributi diventano proprietà dell’oggetto.

Terza Regola - Tutti i tag con un id diventano una variabile con quel nome.

Ammettiamo di avere una classe come la seguente:

public class Contact{ 
            public var home : Location; 
            public var work : Location; 
            public var firstname : String; 
            public var lastname : String; 
            public var isFriend : Boolean = false; 
}

Si può creare un’istanza di questa classe in un file MXML come questa:

<Contact id="myContact" firstname="Susan" lastname="Smith" 
 isfriend="true" />

Parlando in parole povere, questo MXML è equivalente al seguente codice ActionScript:

var myContact : Contact = new Contact(); 
myContact.firstname = "Susan"; 
myContact.lastname="Smith"; 
myContact.isFriend=true;  

Notare come il compilatore MXML riesce a trattare tutti i tipi di corrispondenze senza problemi. Infatti una stringa viene convertita come tale nel caso di un tipo String, e nel caso di un tipo Boolean in un valore true boolean e non in una stringa “true”.

Ma come si comporta nel caso di valori più complessi? Questo è il caso della Quarta Regola.

~

Esempio 2 – tipi complessi

Quarta Regola - (eccezione della prima regola) Se un tag non corrisponde ad una classe, egli viene trattato come una proprietà del tag padre, e i suoi contenuti come valore di tale proprietà.

Prendiamo ad esempio ora una classe Location definita nel modo seguente:

public class Location{  
         public var address : String;  
         public var state : String;  
         public var zip : String; 
}

Ora possiamo utilizzare il seguente MXML per popolare un contatto (Contact) con le rispettive locazioni (Location) definite al suo interno:

<Contact id="myContact" firstname="Henry" lastname="Smith"> 
    <home> 
        <Location address="555 Foo Drive" state="CA" zip="94131" /> 
    </home> 
    <work> 
        <Location address="111 Bar St" state="CA" zip="94102" /> 
    </work> 
</Contact>

Parlando in parole povere, questo MXML è equivalente a:

var myContact : Contact  = new Contact(); 
myContact.firstname = "Henry"; 
myContact.lastname="Smith";                  

var temp: Location = new Location(); 
temp.address = "555 Foo Drive";temp.state = "CA"; 
temp.zip="94131" 
myContact.home = temp;                  

temp = new Location(); 
temp.address = "111 Bar St"; 
temp.state = "CA"; 
temp.zip = "94102"; 
myContact.work = temp;

~

Esempio 3 — gli array

Quinta Regola — Molte classi hanno predefiniti delle “default properties”. Questo significa che i tag per queste proprietà (quarta regola) possono essere omessi.

Sesta Regola — Il tag Array in MXML può essere quasi sempre omesso.

Ammettiamo di voler creare un oggetto ContactList come segue (ignoriamo per ora il metadata):

[DefaultProperty("contacts")] 
public class ContactList{ 
      public var contacts : Array; 
}

Senza le regole 5 e 6 si ottene rebbe qualcosa del genere (che corrisponde alla maniera di lavorare di Flex 1.5):

<ContactList id="myList"> 
        <contacts> 
 	        <Array> 
                            <Contact firstname="Henry" lastname="Smith" /> 
                            <Contact firstname="Susan" lastname="Smith" /> 
 	        </Array> 
 	</contacts> 
</ContactList>

Siccome abbiamo aggiunto un metadata che dice che contacts è la proprietà di default, possiamo usare le regole 5 e 6 per comprimere il codice nel seguente modo:

<ContactList id="myList"> 
    <Contact firstname="Henry" lastname="Smith" /> 
    <Contact firstname="Susan" lastname="Smith" /> 
</ContactList>

~

Perchè tutto ciò è fantastico?

Questo meccanismo ti permette di fare le seguenti tre cose:

1. Semplifica la vita nel caso si abbia una serie di tag che si vuole utilizzare nell’MXML.
2. Diversamente, nel caso si necessiti di creare un file XML relativo ad una generica classe, il mappaggio è già pronto.
3. Dopo qualche ora di lavoro sarà semplice “vedere” nel codice MXML il relativo codice ActioScript che si vuole scrivere per accedere a determinate proprietà. Questo comporta un maggiore risparmio di tempo ed una maggiore produttività.