Recursos compartidos, conflictos, acceso compartido - 1

"¡Hola, amigo! Quiero hablarte sobre compartir recursos. A través de diferentes hilos, naturalmente.

"Sigo hablando de los problemas que ocurren cuando se trabaja con múltiples subprocesos y cómo resolverlos. Esto no significa que usar subprocesos sea malo. Los subprocesos son una herramienta muy poderosa. De hecho, te permiten hacer que tu programa sea más rápido y parejo". más confiable Cuanto más complejo es un programa, más subprocesos y varias partes independientes tiene ".

"Dividir un programa en partes independientes (ligeramente acopladas) es muy beneficioso".

"Imagine que su programa está dividido internamente en 100 subprocesos. Pero solo tiene un procesador de doble núcleo. Esto significa que, en promedio, se ejecutarán 50 subprocesos en cada núcleo".

"Si necesita aumentar el rendimiento del programa, simplemente compre un servidor de dos procesadores y un par de procesadores excelentes para él. Esto podría brindarle hasta 32 núcleos, lo que generaría un aumento del rendimiento de 2 a 20 veces. Dependiendo del número de partes verdaderamente independientes en que se divide".

"Esta es una de las razones por las que Java domina en el desarrollo empresarial. Si una empresa tiene un programa interno complejo escrito por 20 desarrolladores, entonces es mucho más barato comprar otro servidor que duplicar el rendimiento del programa a través de la optimización".

"Así que de eso se trata".

"¡Pero! Cada vez que un desarrollador decide usar otro subproceso, resuelve un problema y crea dos. Más y más subprocesos no aumentarán infinitamente el rendimiento del programa".

"Primero, cualquier programa tiene un trabajo que no se puede dividir y ejecutar en paralelo en diferentes subprocesos. Segundo, todos los subprocesos se ejecutan en el mismo procesador. Cuantos más subprocesos tenga, más lento funcionará cada uno".

"Y, lo que es más importante, los subprocesos a menudo usan los mismos objetos (generalmente llamados 'recursos compartidos')".

"Por ejemplo, un subproceso desea guardar información sobre el trabajo que ha completado en un archivo. Si hay varios subprocesos de este tipo y desean escribir información en el mismo archivo, interferirán entre sí. Para evitar que el archivo se convierta en un lío desordenado, el acceso al archivo es limitado, es decir, mientras un subproceso usa el archivo, otros esperan".

"Sí, lo recuerdo. Lo haces usando la palabra clave sincronizada ".

"Exactamente correcto."

"¿Y si los subprocesos están escribiendo en archivos diferentes?"

"Formalmente, estos son objetos diferentes, pero probablemente estén en el mismo disco duro".

"Entonces, ¿es realmente posible paralelizar algo dentro del procesador?"

"Técnicamente, sí, pero tan pronto como su subproceso necesite algo además de los datos que tiene, ese algo ya podría estar ocupado por otro subproceso, y su subproceso tendrá que esperar".

"Bueno, ¿qué debo hacer entonces? ¿Cómo sé si debo hacer muchos hilos o no?"

"Esto está determinado directamente por la arquitectura de su programa. Cada proyecto tiene su propio 'arquitecto' que conoce todos los 'recursos' utilizados en el programa, conoce sus limitaciones y qué tan bien o mal están paralelizados".

"¿Y si no lo sé?"

"Hay dos opciones:"

a) trabajar bajo la supervisión de alguien que no

b) obtener algunos bultos averiguando por su cuenta

"Soy un robot: no tengo bultos, solo abolladuras".

"Bueno, entonces hazte algunas abolladuras".

"Ya veo. Gracias. Aclaraste algunas cosas que ya había comenzado a dudar".