Chuleta de procesos

1.1Introducción a los procesos

PCB (Process Control Block)

Cada proceso tiene un PCB con lo que el SO necesita para ejecutarlo:

• El código del programa que se ejecuta.
• Los datos que utiliza.
• El estado del procesador: los valores de los registros, incluido el PC (Program Counter).

Ejecución de procesos

Al ejecutar una app (navegador, reproductor de música…), el SO crea un proceso y se encarga de:

• Cargar el ejecutable en memoria.
• Asignarle recursos (CPU, memoria, ficheros…).
• Gestionar su ciclo de vida.

Herramientas para ver los procesos

1.2Estados de un proceso y planificación

• Nuevo: creado, aún no se ejecuta.
• Preparado (ready): listo, esperando la CPU.
• Ejecución (running): usando la CPU.
• Bloqueado (waiting): esperando un recurso o evento, como leer un fichero. Cuando llega, vuelve a Preparado, no a Ejecución.
• Finalizado (terminated): ha acabado.

Planificadores

En los sistemas suele haber muchos más procesos que CPUs. Como necesitan la CPU para ejecutarse, el SO necesita un planificador que decida qué proceso se ejecuta y cuándo.

Es el esquema de los apuntes con las dos flechas que faltaban en el original (modelo de 7 estados): de Bloqueado a Preparado, en memoria y fuera de memoria. Un bloqueado nunca pasa directamente a ejecución. El planificador a medio plazo puede sacar a un proceso preparado o bloqueado al swap («fuera de memoria») y luego devolverlo. Si un bloqueado fuera de memoria recibe su evento, pasa a preparado fuera de memoria.

Algoritmos de planificación

1.2bEl planificador paso a paso para practicar

En el examen te pueden dar una tabla de procesos y pedirte el orden de ejecución (diagrama de Gantt) y los tiempos. Estas son las dos fórmulas:

La ráfaga es lo que necesita de CPU. En los no expulsivos, la espera también es inicio − llegada.

Cola de RR: el que agota el quantum va al final, detrás de los que han llegado mientras tanto. t=2: cola [P2, P1] · t=4: [P1, P3, P2] · t=6: [P3, P2, P4, P1].

1.3Introducción a los hilos

Un hilo de ejecución (thread) es la unidad básica de ejecución dentro de un proceso.

• Cada proceso tiene como mínimo un hilo.
• Los hilos del mismo proceso comparten memoria y recursos (ficheros, conexiones de red…).
• Por eso son mucho más ligeros que crear procesos nuevos.

Ejemplo: un navegador web (proceso) puede tener un hilo para la interfaz gráfica, otro que descarga ficheros y otro que reproduce la música de una pestaña. Todo pasa a la vez dentro del mismo proceso.

De hilos solo entra esta introducción: la programación con hilos en Java es del apartado «fils».

1.4Programación concurrente

Hay concurrencia cuando en un dispositivo se ejecutan de forma simultánea diferentes tareas (procesos). No siempre significa paralelismo real.

Objetivos de la concurrencia

• Mejorar el tiempo de respuesta: un navegador puede cargar imágenes mientras sigue mostrando texto.
• Aprovechar mejor los recursos: mientras un proceso espera datos del disco, otro usa la CPU.
• Facilitar la modularidad: es más natural dividir una aplicación en tareas independientes.

Concurrencia con procesos y con hilos

Problemas típicos de la concurrencia

1.5Programación paralela y distribuida

Ejemplos de aplicaciones distribuidas: Google Search (miles de servidores procesan búsquedas y combinan los resultados), P2P como torrent (los ordenadores comparten fragmentos de un fichero) y videojuegos multijugador (cada jugador ejecuta parte de la simulación y los servidores coordinan).

1.6Gestión de procesos y monitorización

Una vez creados, el SO y los administradores o desarrolladores tienen que gestionar los procesos. Esto incluye:

• Consultar qué procesos hay en ejecución.
• Obtener información: PID, consumo de CPU, memoria, estado…
• Finalizar o suspender procesos que no responden o que hay que detener.
• Depurarlos y comprobar que funcionan.

Cada proceso tiene un PID (Process ID) único que le asigna el SO. Con él se le pueden enviar señales, consultar su estado o finalizarlo. El PPID (Parent Process ID) es el PID del proceso padre que lo creó. En Linux, ps -ef muestra las dos columnas; en Windows, el Administrador de tareas muestra el PID.

1.7Comunicación entre procesos (IPC)

Cuando dos o más procesos se ejecutan, a menudo tienen que intercambiar información: enviar datos, recibir resultados o coordinarse. Esto es la IPC (Inter-Process Communication), y el SO ofrece varios mecanismos.

Ejemplos: un proceso lee un sensor y otro muestra los datos en pantalla; un navegador lanza otro proceso para los plugins y los dos se comunican; en ls | grep .java la salida de un proceso es la entrada del otro.

Hay técnicas sencillas (ficheros, pipes) y otras más potentes (sockets, memoria compartida, mensajes). Se escoge según si la comunicación es local o distribuida, si hace falta velocidad o persistencia, y si los procesos están fuerte o débilmente acoplados.

Redirecciones de la shell

1.8Sincronización entre procesos

Cuando dos o más procesos acceden al mismo recurso sin coordinarse, puede haber condiciones de carrera. Por ejemplo, dos procesos escriben en el mismo fichero a la vez y el resultado es inconsistente.

Necesidad de sincronización

El SO ofrece mecanismos para coordinar el acceso a los recursos compartidos. Aseguran que:

• Solo un proceso pueda modificar el recurso en un momento dado.
• Los procesos esperen su turno antes de continuar.
• El resultado final sea correcto y determinado.

Mecanismos de sincronización entre procesos

1.9Programación de aplicaciones multiproceso

Cómo crea y gestiona procesos Java, y cómo se comunican: la parte práctica de todo lo anterior.

La clase Runtime · LaunchProcess.java

package runtime;

public class LaunchProcess {
    // private static final String PROGRAM = "notepad"; // Windows
    // private static final String PROGRAM = "gedit";   // Linux
    private static final String PROGRAM = "pluma";      // Linux

    public static void main(String[] args) {
        try {
            Process process = Runtime.getRuntime().exec(PROGRAM);   // lanza el editor
            process.waitFor();                                       // espera a que lo cierres
            System.out.println(PROGRAM + " has been closed.");
        } catch (IOException e) {
            e.printStackTrace();
            System.exit(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
            Thread.currentThread().interrupt();
            System.exit(2);
        }
        System.exit(0);
    }
}

Runtime.getRuntime().exec(...) lanza un proceso externo y process.waitFor() hace que el programa Java espere a que acabe.

La clase Process

ListFiles.java con Runtime (package process)

private static final String COMMAND = "ls";   // Windows: "dir"
...
Process process = Runtime.getRuntime().exec(COMMAND);
System.out.printf("Started process %d: %s%n", process.pid(), String.join(" ", COMMAND));
process.getInputStream().transferTo(System.out);                  // lo que imprime ls → a nuestra consola
System.out.printf("Process %d exited with code: %d%n", process.pid(), process.waitFor());

La clase ProcessBuilder (la recomendada)

Java recomienda ProcessBuilder frente a Runtime.exec() porque da más control sobre los argumentos, permite redirigir la entrada y la salida a ficheros o a otros flujos, y su configuración es más clara y flexible.

ListFiles.java con ProcessBuilder (package procesbuilder)

// private static final String[] COMMAND = {"dir", "/n"};   // Windows
private static final String[] COMMAND = { "ls", "-l" };       // Linux: orden y argumentos separados
...
ProcessBuilder processBuilder = new ProcessBuilder(COMMAND);
Process process = processBuilder.start();                         // ejecuta el proceso
System.out.printf("Started process %d: %s%n", process.pid(), String.join(" ", processBuilder.command()));
process.getInputStream().transferTo(System.out);                  // la salida se lee igual que con Runtime
System.out.printf("Process %d exited with code: %d%n", process.pid(), process.waitFor());

RedirectOutput.java

processBuilder.redirectOutput(new File(OUTPUT_FILE));   // la salida va directamente a output.txt
// también existen redirectInput(File) y redirectError(File)

Pipes.java · conectar dos procesos a mano

private static final String[] COMMAND_1 = { "ls" };            // Windows: {"dir"}
private static final String[] COMMAND_2 = { "grep", "txt" };   // Windows: {"findstr", "txt"}
...
Process process1 = new ProcessBuilder(COMMAND_1).start();
Process process2 = new ProcessBuilder(COMMAND_2).start();

// Conectar la salida de process1 con la entrada de process2
InputStream inputStream = process1.getInputStream();     // lo que imprime ls (el padre LEE)
OutputStream outputStream = process2.getOutputStream();  // la entrada de grep (el padre ESCRIBE)
inputStream.transferTo(outputStream);                    // pasa todo de ls a grep
outputStream.close();   // ⚠️ importante: así grep sabe que no hay más datos

process2.getInputStream().transferTo(System.out);        // resultado final de grep
System.out.printf("Process %d exited with code: %d%n", process1.pid(), process1.waitFor());
System.out.printf("Process %d exited with code: %d%n", process2.pid(), process2.waitFor());

Pipeline.java · lo mismo, automático

private static final String[][] PIPE_LINE = { COMMAND_1, COMMAND_2 };
...
List<ProcessBuilder> processBuilders = new ArrayList<>();
for (String[] command : PIPE_LINE) {
    processBuilders.add(new ProcessBuilder(command));
}
List<Process> processes = ProcessBuilder.startPipeline(processBuilders);   // arranca y conecta ls → grep
for (int i = 0; i < PIPE_LINE.length; i++) {
    System.out.printf("Started process %d: %s%n", processes.get(i).pid(),
            String.join(" ", processBuilders.get(i).command()));
}
Process last = processes.get(processes.size() - 1);    // el último tiene el resultado
last.getInputStream().transferTo(System.out);
for (Process p : processes) {
    System.out.printf("Process %d exited with code: %d%n", p.pid(), p.waitFor());
}

1.9bEntrada y salida: quién escribe y quién lee

La regla para no liarte: mírala siempre desde el padre (tu programa Java). Si el padre lee algo del hijo, es un InputStream. Si el padre escribe algo al hijo, es un OutputStream.

1.9cPlantilla de los ejercicios y variantes

Las clases de los apuntes (LaunchProcess, ListFiles, RedirectOutput, Pipes y Pipeline) siguen todas la misma plantilla. Si la entiendes, en cada ejercicio solo cambia la línea del medio. Las marcadas como extra no salen en los apuntes: son variantes con los mismos métodos para practicar.

public class RedirectOutput {
    private static final String OUTPUT_FILE = "output.txt";
    // private static final String[] COMMAND = {"cmd", "/c", "dir"};   // Windows
    private static final String[] COMMAND = { "ls", "-l" };          // Linux: cada argumento por separado

    public static void main(String[] args) {
        try {
            ProcessBuilder processBuilder = new ProcessBuilder(COMMAND);   // 1. la receta
            processBuilder.redirectOutput(new File(OUTPUT_FILE));        // 2. ⭐ lo que cambia en cada ejercicio
            Process process = processBuilder.start();                      // 3. arrancar (IOException)
            System.out.printf("Started process %d: %s%n", process.pid(),
                    String.join(" ", processBuilder.command()));         // PID y comando lanzado
            System.out.printf("Process %d exited with code: %d%n",
                    process.pid(), process.waitFor());                      // 4. esperar (InterruptedException)
        } catch (IOException e) {           // no se pudo lanzar: comando que no existe, fichero que no se abre…
            e.printStackTrace();
            System.exit(1);
        } catch (InterruptedException e) {  // nos interrumpieron mientras esperábamos
            e.printStackTrace();
            Thread.currentThread().interrupt();
            System.exit(2);
        }
        System.exit(0);                       // todo bien
    }
}

P1Varios procesos, un extracto: FileLock

Cada entidad (titular, empresa…) ejecuta su propio BankProcess: si lo lanzas 3 veces, son 3 procesos con su memoria, su consola y su PID. Lo único que comparten es statement.txt, el recurso compartido. Escribir en él es la sección crítica.

public void writeOperation(Operation operation, String concept, double amount) {
    String linea = fecha + " | " + operation + " | " + concept + " | " + signo + importe + " €\n";

    try (FileOutputStream fos = new FileOutputStream(fileName, true);   // true = append
         FileLock lock = fos.getChannel().lock()) {                // 🔒 si otro lo tiene, ESPERA aquí
        fos.write(linea.getBytes(StandardCharsets.UTF_8));          // sección crítica
    } catch (IOException e) {
        System.err.println("Error: " + e.getMessage());
    }   // 🔓 el try-with-resources libera el lock y cierra el fichero (orden inverso)
}

La demostración (rúbrica)

• Quitar la sincronización: escribiendo sin lock y letra a letra, el fichero sale mezclado (22002266--1100…) → condición de carrera.
• Volver a poner el lock: el segundo proceso espera y las líneas salen enteras.
• En el debugger: breakpoint en fos.write. Con lock, B no llega al breakpoint: sale como Running, atascado en lock(). Sin lock, los dos se paran a la vez.

# Lanzar varios procesos y gestionarlos (desde la carpeta del proyecto)
java -cp bin bank.BankProcess          # en 2 o 3 terminales
jps -l                                  # PID de cada proceso Java
ps -ef | grep BankProcess               # alternativa con ps (PID y PPID)
kill 4117                               # SIGTERM: pide que termine
kill -9 4117                            # SIGKILL: lo mata al instante

P212 tuberías en paralelo: ProcessBuilder

BankFilter hace desde Java lo mismo que esta línea de shell, pero para los 12 meses a la vez:

java StatementFilter amount -gt 100 < statement-01.txt | java StatementFilter amount -lt 200 >> filter.txt

Cada filtro es un proceso: 2 filtros × 12 meses = 24 procesos a la vez. StatementFilter lee de System.in y escribe en System.out, como un grep. Resultado: solo los SUPERMERCAT de 120 € (52 líneas).

public static void main(String[] args) throws IOException {
    deleteOldOutput();                                       // filter.txt se escribe en append
    List<Process> lastPipelineProcesses = startAllPipelines(); // fase 1: arrancar, SIN esperar
    collectOutputs(lastPipelineProcesses);                    // fase 2: recoger en orden
    System.exit(0);
}

private static Process startPipeline(String fileName) throws IOException {
    List<ProcessBuilder> builders = createProcessBuilders();          // un builder por filtro
    builders.get(0).redirectInput(new File("bank", fileName));      // solo el 1º lee el fichero  (= <)
    List<Process> processes = ProcessBuilder.startPipeline(builders); // arranca y conecta  (= |)
    return processes.get(processes.size() - 1);                       // el último tiene el resultado
}

private static void collectOutputs(List<Process> last) throws IOException {
    try (FileOutputStream fos = new FileOutputStream(OUTPUT_FILE, true)) {   // (= >>)
        for (Process process : last) {
            process.getInputStream().transferTo(fos);   // espera solo si ese mes no ha acabado
        }
    }
}

Lo que pide la rúbrica de la parte 2

# Ejecutar el filtro a mano con redirecciones (¡si no sabes, suspendes la parte 2!)
java -cp bin bank.filter.StatementFilter amount -gt 100 < bank/statement-01.txt > salida.txt
java -cp bin bank.filter.StatementFilter amount -gt 100 < bank/statement-01.txt | java -cp bin bank.filter.StatementFilter amount -lt 200 > enero.txt

# Un filtro sin < se queda esperando teclado: así puedes buscarlo y matarlo
java -cp bin bank.filter.StatementFilter concept -eq super
jps -l        # en otra terminal
kill 5230

# Modificar la pipeline: retiradas de 100 € o más
{ "java", "-Duser.dir=bin", FILTER_CLASS, "operation", "-eq", "withdraw" },
{ "java", "-Duser.dir=bin", FILTER_CLASS, "amount", "-ge", "100" }

Operadores de StatementFilter: columnas operation y concept con -eq/-ne (en concept, -eq significa «contiene»); amount con -lt -le -eq -ge -gt -ne. El importe se compara sin signo.