Alternativa open source per lo sviluppo di applicazioni real time: http://www.rtai.org.

Questa estensione hard Real-Time realizzata dal Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano (DIAPM) è una suite di aggiornamenti e librerie che consente comunque le normali funzionalità di un normale kernel Linux. La differenza con il normale Linux non riguarda soltanto le modifiche al kernel, bensì consiste anche nell’introduzione di RTAILab: un insieme di librerie e strumenti per sviluppare diagrammi a blocchi che possono essere compilati ed eseguiti su Linux RTAI. I diagrammi possono essere creati con Scilab/Scicos (Open Source) o Matlab/Simulink/RTW (commerciale).

Quando la CPU rileva un segnale di interrupt, libera il bus dati ed abilita il dispositivo in attesa ad inviare l'interrupt vector. Un interrupt vector è l'indirizzo di memoria di un interrupt handler (la routine di gestione dell'interrupt), o un indice in un array chiamato interrupt vector table o dispatch table. Una Interrupt vector table contiene gli indirizzi di memoria degli interrupt handler.

Dopo la generazione di un interrupt, il processore salva il suo stato di esecuzione ed avvia l'esecuzione dell' interrupt handler corrispondente all'interrupt vector.

Gli eventi di VxWorks sono un meccanismo di comunicazione tra task e interrupt routine (ISR), tra task ed altri task o task e oggetti VxWorks. Gli oggetti VxWorks sono definiti anche risorse e includono i semafori e le code di messaggi. Gli eventi possono essere inviati dai task, dalle ISR e dalle risorse, mentre possono essere ricevuti solo dai task.

Affinché un task possa ricevere un evento è necessario che si registri sulla risorsa e affinché una risorsa possa inviare un evento è indispensabile che sia libera. Gli eventi assomigliano ai segnali, nel senso che solo i task registrati possono ricevere un evento da una particolare risorsa, ma al contrario di quello che succede con i segnali, uno stesso task può essere registrato per ricevere gli eventi di più risorse: uno stesso task può attendere che un determinato semaforo diventi libero e che un messaggio arrivi in una particolare coda di messaggi.

Un'altra differenza degli eventi rispetto ai segnali consiste nel fatto che sono sincroni: un task in attesa di un particolare evento rimane bloccato finché l'evento non si verifica, ma una volta che l'evento è stato ricevuto il task prosegue la propria esecuzione.

Un task può rimanere in attesa anche di un evento che non è collegato ad una risorsa specifica, ma semplicemente inviato da un altro task o da una ISR: in questo caso non è necessario che il task si registri per la ricezione dell'evento, ma è sufficiente che chi lo invia conosca qual'è il task interessato a riceverlo.

Infine due task non possono registrarsi per ricevere un evento da una medesima risorsa: la registrazione del secondo task comporta o la restituzione di un errore o la de-registrazione automatica del primo task.

Poiché nel sistema operativo VxWorks tutti i task esistono nello stesso spazio degli indirizzi, è evidente che ogni variabile globale risulta automaticamente condivisa tra tutti i task. Se da un lato questa caratteristica rende semplice lo scambio delle informazioni tra i task, dall'altro impone l'adozione di un meccanismo che impedisca l'accesso contemporaneo in scrittura di tali variabili così da evitare l'inconsistenza dei dati.

Il sistema più efficiente rendere esclusivo l'accesso alle risorse condivise, consiste nell'utilizzare un semaforo binario.

Il primo passo consiste nel creare il semaforo binario come disponibile (pieno):

Ogni volta che un task vuole accedere alla risorsa condivisa, deve prima acquisire il semaforo creato in precedenza e rilasciarlo ed alla fine delle operazioni:

I semafori binari possono essere utilizzati efficacemente anche per sincronizzare l'esecuzione di due o più task; in questo caso il semaforo rappresenta la condizione di attesa del task da sincronizzare. Il semaforo è creato come non disponibile (vuoto) ed è utilizzato per bloccare l'esecuzione del task che deve essere sincronizzato, un secondo task, quando si verifica la condizione o l'evento atteso, rilascia il semaforo permettendo al primo task di proseguire la sua esecuzione.

Se più task dovvessero essere sbloccati a seguito di un evento, il task che solleva l'evento di sincronizzazione può sfruttare la funzione semFlush(), che sblocca tutti i task in attesa di uno stesso semaforo.

ReactOS è un sistema operativo open source compatibile con le applicazioni ed i driver sviluppati per il sistema operativo Microsoft Windows XP. Il team di sviluppo non intende creare un clone del sistema operativo di casa Microsoft, ma persegue l'obiettivo di raggiungere la piena compatibilità binaria con le applicazioni ed i driver delle periferiche per i sistemi operativi NT e XP, usando un'architettura simile e fornendo un'interfaccia pubblica completa e equivalente.

Questo sistema operativo nasce dalla considerazione che, sebbene Linux sia un ottimo O.S., non può rappresentare la risposta giusta per tutti: vi sono persone a cui Windows piace ed aziende troppo abituate all'utilizzo di applicativi Windows, ma che al contempo sono insoddisfatti della politica commerciale di Microsoft; ReactOS vuole essere una valida alternativa per soddisfare i gusti e le necessità di questa tipologia di utenti.