Todos os computadores modernos conseguem executar várias tarefas ao mesmo tempo, como o ler de um disco, enquanto corre uma aplicação de um utilizador, etc...

No entanto o CPU apenas corre um programa de cada vez, mas vai saltando de programa em programa em poucos milisegundos (consoante as tarefas a executar), dando ao utilizador a ilusão de paralelismo.

Este modo de funcionamento (pseudo-paralelismo) torna-se algo difícil de lidar, pelo que os programadores de sistemas operativos têm desenvolvido um modelo que torna o pseudo-paralelismo mais fácil de ocorrer, trabalhar e lidar.

Neste modelo todo o software que é susceptível de ser executado, incluindo o S.O. é organizado num número sequencial de processos.

O processo é basicamente um programa em execução, que inclui os valores correntes dos contadores, registos, e variáveis do mesmo.

Conceptualmente cada processo tem o seu CPU virtual, mas na realidade o CPU vai variando de processo em processo. Para entender melhor o sistema torna-se mais fácil pensar numa colecção de processos a correr num pseudo-paralelismo, do que tentar seguir o processamento sequencial de cada um deles. Esta variação de processamento sobre os vários processos, é chamada de multiprogramação.

Com o CPU a saltar de processo em processo, a velocidade a que cada processo executa a sua computação não vai ser uniforme, provavelmente nem vai haver possibilidade de a repetir. Pelo que os processos não devem ser programados com afirmações relativas ao "Timing" de cada um. Normalmente a maioria dos processos não é influenciada pelo multiprocessamento feito pelo CPU.

A diferença entre processos e programas, é pequena mas crucial. Para ajudar a exemplificar tal diferença, vamos utilizar uma analogia própria.

Imaginemos um cientista, que se encontra a confeccionar um bolo para o seu filho. Ele tem a receita e todos os ingredientes necessários á realização do bolo. Neste caso a receita é o programa, o cientista é o CPU, e os ingredientes do bolo, os dados de entrada. Os processos são as actividades necessárias á confecção do bolo, como o ler da receita, o ir buscar os ingredientes, cozer o bolo, etc...

Imaginemos agora, que o filho do cientista entra pela cozinha a dizer que tinha sido picadi por uma abelha. O cientista pára a execução do bolo, memoriza o estado da confecção onde ficou ( o estado actual do processo é gravado), e inicia os cuidados médicos necessários ao seu filho ( corre outro programa e consequentemente outros processos).

Depois de terminados os primeiros socorros do filho, este retoma a confecção do bolo no ponto em que a tinha deixado.

A ideia principal, é de que o processo é uma actividade de qualquer tipo, que contém variáveis de entrada e saída, e um estado. Um processador, pode ser partilhado por entre os vários processos, utilizando um algoritmo de escalonamento entre os vários existentes, que determina quando iniciar e parar a execução de um processo e quando passar a um processo diferente.

Os S.O. que suportam o funcionamento de processos, têm de ter uma forma de criar e gerir todos os processos necessários.

Em sistemas simples ou sistemas que suportam uma única aplicação, é possível termos todos os processos necessários ao funcionamento das aplicações referenciados e prontos a correr, logo na inicialização do sistema.

No entanto, a maioria dos sistemas, necessita de uma forma de criar e eliminar processos, á medida que estes vão sendo necessários.

Nos sistemas UNIX, os processos são executados pelo comando "FORK", quando um processo executa este comando, é criada uma cópia idêntica do processo original ("Filho"), ficando estas a correr em paralelo com os processos "pais". Como se pode deduzir, em seguida e á medida que o programa progride, podemos ter uma longa estrutura de processos diferentes em árvore.

No MS-DOS, existe uma "chamada do sistema" que carrega um ficheiro binário específico para a memória, executa-o como um processo "Filho". Mas ao contrário dos S.O. UNIX, O MS-DOS barra a progressão do processo "Pai" até o processo "Filho" estar acabado. Assim os processos parentes não correm em paralelo.

Cada processo é uma entidade diferente, com o seu próprio controlador de programa e estado interno. No entanto, frequentemente os processo necessitam de interagir com outros processos. Um processo pode gerar uma resposta que outro irá utilizar.

Um processo bloqueia quando já não é logicamente possível continuar a sua execução, tipicamente porque está à espera de uma entrada que ainda não se encontra disponível. É ainda possível bloquear um processo que está conceptualmente pronto e capaz de correr apenas porque o sistema decidiu alocar o CPU, para outro processo durante algum tempo.

No primeiro caso o bloqueio do processo é inerente ao problema (não é possível processar uma entrada do utilizador, enquanto a mesma não ocorrer).

No segundo caso é uma técnica do sistema, que resulta da falta de CPUs.

Na figura seguinte, podemos observar um diagrama de estados onde se encontram representados os vários estados que um processo pode ter:

Logicamente os dois primeiros termos, são similares. Em ambos os casos o processo está pronto a correr mas no segundo, não há CPU disponível para tal. O terceiro estado é diferente dos restantes, porque este não pode correr mesmo que haja tempo de CPU para o fazer.

Como se pode observar pela figura, existem quatro transições possíveis. A transição um, ocorre quando um processo descobre que não pode continuar. Em alguns sistemas o processo tem de executar uma instrução "Block", para passar ao estado 3. Mais comunmente quando um processo lê de um terminal ou de um ficheiro especial, e não há nenhuma entrada de um utilizador disponível, este é bloqueado automaticamente.

As transições 2 e 3, são causadas pelo agendamento dos processos (Parte do S.O.), sem que o próprio processo saiba.

A transição 2, ocorre quando o agendamento de processos conclui que o processo em execução já ocupou o CPU tempo suficiente, e que é tempo de avançar com um outro processo.

A transição 3, ocorre quando todos os outros processos já tiveram o seu tempo de CPU, e é tempo de regressar ao primeiro.

O conceito de agendamento de processos, ou seja, a decisão de qual o processo a correr, e durante quanto tempo, é importante. Vários algoritmos foram desenvolvidos para balancear os requisitos de eficiência do sistema como um todo e de forma o mais equivalente possível, para os diferentes processos.

A transição 4 ocorre quando chega o evento externo pelo qual o processo estava à espera. Se na altura mais nenhum processo estiver a decorrer arrancará de imediato a transição 3, e o processo começará a correr. Caso esteja mais algum processo a decorrer será necessário aguardar até que o CPU esteja disponível.

Através do modelo de processos é mais fácil entender o que se passa dentro do sistema. Assim temos dois tipos de processos: Alguns correm programas que executam comandos inseridos pelo utilizador. Outros processos fazem parte do próprio sistema e destinam-se a administrar tarefas, como por exemplo satisfazer requisitos de programas ou de gerenciar o funcionamento de discos e disquetes.