Exclusión mutua, interbloqueos y comunicación en sistemas concurrentes

Exclusión mutua

Poner correctamente bajo exmut los recursos compartidos, si no se producirán interferencias no deseadas entre procesos, provocando corrupción de datos compartidos. Si esto ocurre, hay una condición de carrera.

Ausencia de interbloqueos: 2 procesos se bloquean mutuamente cuando están esperando el uno al otro y no pueden continuar su ejecución mientras esperan. Interbloqueo activo (livelock) - cuando los procesos ejecutan instrucciones que no producen un avance real del programa, solo sirven para sincronizarse entre sí. Interbloqueo pasivo (deadlock) - cuando todos los procesos están bloqueados esperando indefinidamente. Este interbloqueo solo se produce con herramientas de sincronización.

Ausencia de retrasos innecesarios: los procesos deben progresar en su ejecución si no hay otro proceso compitiendo con él para entrar en las secciones bajo exclusión mutua.

Ausencia de inanición: todo proceso que quiera acceder a un recurso compartido deberá poder hacerlo en algún momento.

Tipos de modelos de paso de mensajes

Identificación de procesos:

• Comunicación directa simétrica - el emisor indica el ID del receptor y viceversa (esta identificación puede hacer el sistema poco flexible a futuras ampliaciones).
• Comunicación indirecta asimétrica - el emisor conoce el ID del receptor pero no al revés (es más flexible que el otro, usado en arquitecturas cliente/servidor en sistemas distribuidos).
• Comunicación indirecta - el emisor envía a un buffer o buzón intermedio y depende de restricciones aplicadas a estos: varios procesos pueden recibir mensajes de una misma cola o ser exclusiva la cola para cada proceso, un mensaje enviado a una cola puede ser recibido por un único proceso o por todos, un mismo proceso puede enviar un mensaje a varias colas, las colas pueden ser estáticas o dinámicas.

Sincronización:

• Comunicación síncrona - emisor y receptor coinciden en el mismo instante de la comunicación.
• Comunicación asíncrona - coinciden en el tiempo pero no en el mismo instante.

Características del canal de comunicación: flujo de datos, capacidad del canal, tipo y tamaño, ordenación y fiabilidad del envío.

Lambda y clases anónimas

Lambda - son una forma compacta de pasar a un método código como parámetro, se puede utilizar en todos aquellos lugares en los que se espere un objeto que implementa una interfaz con un único método. Clases anónimas - en versiones anteriores, la forma habitual de pasar código como parámetro era usando clases anónimas. Las clases anónimas son una forma compacta de implementar una clase completa dentro de un método. En la misma sentencia se declara la clase y se crea un objeto de dicha clase. Una anónima no tiene nombre.

Anónimas vs lambda: las expresiones lambda son más eficientes en tiempo de ejecución que las clases anónimas y son más compactas de escribir. Una clase anónima es una clase completa (puede tener clase padre, atributos, etc.), una lambda solo puede usarse donde se espere una interfaz con un método. Si se usa 'this' en una clase anónima, se referencia al objeto de la clase anónima. Si se hace en lambda, se referencia al objeto donde se está declarando la lambda. Un lenguaje de programación se puede considerar funcional si permite manejar funciones: asignar funciones a variables, pasar funciones como parámetro, definir funciones anónimas en los mismos lugares que se puede poner un valor o una expresión.

Objetos compartidos entre hilos

Un objeto se puede compartir entre varios hilos sin problemas si:

• Se accede a los métodos bajo exclusión mutua.
• La clase de ese objeto está preparada para la ejecución concurrente de sus métodos.
• Los objetos no se modifican durante el tiempo que se comparten entre hilos.
• La clase es inmutable.

Thread-safe: los objetos de la clase se pueden compartir entre hilos sin necesidad de ponerlos bajo exclusión mutua. Todas las clases inmutables son thread-safe. Para implementarla, hay que asegurarse de que todos sus métodos se pueden ejecutar por varios hilos de forma concurrente sin condiciones de carrera ni intercalaciones no deseadas. Esto se puede lograr haciendo la clase inmutable, sincronizando los hilos de alguna manera o con atributos thread-safe.

Streams vs colecciones

Streams: secuencia de elementos, se pueden calcular según se van procesando, información volátil que solo se puede procesar una vez, tamaño infinito, tiene versiones eficientes para tipos primitivos. Colecciones: elementos que se pueden procesar en secuencia o con acceso directo, tienen que estar en memoria antes de procesarse, estructuras de datos en memoria, tamaño finito, no tiene versiones para tipos primitivos.

Operaciones:

• Intermedias: se procesan de forma perezosa (map, filter).
• Terminales: inician computación y devuelven un objeto, valor, lista (sum).

Aplicaciones concurrentes: app interfaz usuario, app web, bases de datos. Las bases de datos están diseñadas para que varios clientes realicen consultas concurrentemente. Se han optimizado según las estrategias:

• Transacciones: el usuario indica cuando comienza y cuando terminan las operaciones que deben ejecutarse de forma atómica.
• Bloqueos: el usuario indica el nivel de exclusión mutua de la base de datos.
• Bloqueo pesimista: los datos se bloquean para que no se puedan usar por una transacción mientras la otra está utilizando otra (puede limitar el rendimiento de la base de datos innecesariamente).
• Bloqueo optimista: los datos no se bloquean. Cuando una transacción está a punto de terminar, se verifica si los datos que se han leído han cambiado durante la transacción. Si es así, se reintenta la transacción (ofrece mejor rendimiento si no hay muchas transacciones que usan los mismos datos).