Discussione:Processo (informatica)

L'unico motivo di esistenza dei Thread è che consentono una commutazione di contesto meno costosa.--Mauro 13:19, Lug 10, 2005 (CEST)

Non ritengo che questa definizione di processo sia del tutto corretta.

Io la porrei in questi termini: "Processo e programma sono due entità distinte. L'esecuzione di un programma genera uno o più processi, ciascuno dei quali può essere padre di zero o più threads."

La differenza fra processo e thread è che un processo è indipendente, ed ha associati un numero grande di informazioni, oltre che una sua memoria. Data la mole di queste informazioni, la commutazione di processo è lenta, e quindi sono stati introdotti i threads, più snelli e più velocemente commutabili, ma che hanno bisogno di dipendere da un processo-padre e che con esso condividono la memoria."

Non capisco dove siano le inesattezze nell'attuale definizione.

Invece trovo le seguenti inesattezze nella definizione proposta:

"L'esecuzione di un programma genera uno o più processi"

Io direi che l'esecuzione di un programma è un processo, e uno solo. Non si può dire niente su un'esecuzione di un programma senza parlare di un processo, e non si può dire niente di un processo senza parlare di un'esecuzione di un programma; quindi sono la stessa cosa. Per avere più processi da un programma, è necessario eseguire più volte lo stesso programma.

"ciascuno dei quali può essere padre di zero o più threads"

Un processo ha sempre almeno un thread. Non esistono processi con zero thread. Siccome il thread contiene la posizione (o program counter, o instruction pointer), un processo che non ha una posizione non può fare niente. Questo naturalmente in un sistema operativo dotato di thread. Ma forse (sono ignorante in materia) i processi in stato "zombie" di Unix possono non avere nessun thread, perché non hanno niente da fare.

--Carlo.milanesi 19:00, 1 feb 2006 (CET)[rispondi]

Un processo "zombie" è semplicemente terminato, ed il suo padre non ha ancora fatto una chiamata al waitpid per farlo morire definitivamente e distruggerlo. Da un punto di vista pratico, resta solo il suo descrittore nella tavola dei processi, ma tutta la memoria che aveva allocata è già stata liberata (ma non necessariamente altre risorse "critiche" che a livello di kernel devono essere liberate: un socket, una device "hunged-up", o altre porcherie simili). --Samuele 11:55, 22 gen 2007 (CET)[rispondi]

Spero di aver contribuito, con il ritocco del contenuto, a rendere più chiara la differenza tra processi e thread :-) La buon'anima della Norma Lijtmaer ci fece impazzire, sulla definizione :-) --Samuele 11:47, 22 gen 2007 (CET)[rispondi]

Mah, non vedo perchè non si possa dare questa definizione, forse un po' stringata, ma intuitivamente valida. Il processo è quel codice eseguibile caricato in memoria, in stato di "esistente" (quindi in waiting, running, o quant'altro) dal punto di vista dello scheduler, con associate un bel po' di risorse varie. E fin qui siamo tutti d'accordo, direi. Quindi, a parte quando lo scheduler non lo sta considerando perchè sta servendo altri processi da far ruzzare, o quando il kernel aspetta di liberare tutte le risorse a lui associate (zombie, ecc) può essere visto come quel "programma" in esecuzione "insieme" a tutti gli altri processi.

Chi lancia un "ps" vede tutti i processi appartenenti all'utente e considerati "vivi" indipendentemente dal fatto che il processore sia uno o 30. Il punto di vista dell'utente, quindi, è quello del "programma in esecuzione", indipendentemente dal fatto che abbia in quel momento il tempo macchina tutto per lui o meno (esecuzione di un programma). Cosa ti pare che non torni, in questo discorso? Forse andrebbe limata la descrizione per rendere meglio questo concetto?

PS: l'American Heritage Dictionary, alla voce process dice che il processo è un "running software program", mentre il più specialistico "Free On-line Dictionary of Computing" lo definisce come "The sequence of states of an executing program" quindi direi che "programma in esecuzione" può essere una buona traduzione in italiano. Da nessuna parte ho trovato "execution of a program"... o mi sfugge qualcosa? --Samuele 11:58, 2 feb 2007 (CET)[rispondi]

PS: Si potrebbe dire che "il processo è l'idea che ha un SO di un programma in esecuzione. Tale concetto varia da SO a SO, ma in genere si compone di ecc ecc"

PPS: bah io mi sono lanciato e l'ho corretto così, speriamo piaccia ;-) --Samuele 12:26, 2 feb 2007 (CET)[rispondi]

A me non sembra appropriato definire il processo "programma in esecuzione" per il fatto che, se lancio una seconda volta lo stesso programma prima che l'esecuzione precedente sia terminata, nel computer ho due processi per lo stesso programma. In tale situazione, mi pare improprio dire che ho due programmi in esecuzione. Il programma in esecuzione è uno solo, ma è eseguito due volte contemporaneamente, quindi ho due esecuzioni dello stesso programma. --Carlo.milanesi 18:56, 3 feb 2007 (CET)[rispondi]

...allora questa parte non va bene:

  Le definizioni sono le seguenti:
* Il processo è l'oggetto del sistema operativo a cui sono assegnate tutte le risorse 
di sistema per l'esecuzione di un programma, tranne la CPU.
* Il thread è l'oggetto del sistema operativo o dell'applicazione a cui è assegnata la CPU
per l'esecuzione.

Se il thread è definito come parte del processo, allora il processo in esecuzione ha in quel momento assegnata la CPU per l'esecuzione di uno o più dei suoi thread.

Credo che la sottigliezza semantica stia nel concetto di "in esecuzione". Se si considera il processo come una "fune" dotata di vari thread, allora quando un thread è in esecuzione, lo è anche il processo a cui appartiene.

Ci si pensa...?

--Samuele 12:21, 2 feb 2007 (CET)[rispondi]

Anche per me questa definizione andrebbe sistemata, sono d'accordo con Samuele --Alez 19:01, 3 set 2007 (CEST)[rispondi]