[caracas-pm] Hilos en Perl

[Ernesto Hernández-Novich]

On Sat, 2013-12-07 at 16:02 -0430, Alberto Mijares wrote:
> 2013/11/26 Ernesto Hernández-Novich <emhnemhn at gmail.com>:
> > On Sat, 2013-11-02 at 00:32 -0430, Alberto Mijares wrote:
> > [...]
> >> Estoy jugando un poco, de manera didàctica, con el módulo "threads" de
> >> Perl. Quería ver qué tanto podía mejorar un script sencillo que tengo
> >> para redimencionar fotos.
> >
> > Como el trabajo para cambiar las dimensiones de cada foto es
> > independiente entre fotos y por tanto no necesitan estado mutable
> > compartido, pienso que en lugar de complicarte con hilos,
> > Parallel::ForkManager es más fácil de comprender y usar.
> 
> 
> Gracias, Ernesto. Realmente muy fácil y útil.
> 
> Si quieres, cuando tengas tiempo, podrías explicar por aquí cómo
> identificar los casos en los que conviene usar hilos y cuándo es mejor
> lanzar nuevos procesos.

Si las unidades de trabajo son independientes, en el sentido que no
necesiten compartir datos, entonces usar hilos no es una buena idea.
Esto es, si eres capaz de trocear un trabajo grande (digamos, procesar
UNA bitácora muy grande) en unidades independientes más o menos del
mismo tamaño (de la línea 1 a la 100000, de la 100001 a la 200000, y
así) es mejor usar procesos independientes con fork()
(Parallel::ForkManager).

En tu ejemplo, la tarea de cambiar las dimensiones de una foto es
absolutamente independiente de la tarea de cambiar las dimensiones de
otro. Se trata de un caso ideal para Parallel::ForkManager: divide la
cantidad de fotos entre la cantidad de núcleos que vas a dedicar al
proceso, genera un proceso para cada conjunto de fotos y que hagan su
trabajo en paralelo.

Si las unidades de trabajo tienen que compartir datos *mutables* entre
si y el algoritmo es paralelizable, entonces en Perl (y otros lenguajes
imperativos), no te queda más remedio que usar hilos, mutexes y
entregarte al maravilloso mundo de las condiciones de carrera.

No hay reglas automáticas para decidir por uno u otro, pero en lenguajes
imperativos hay que hacer un esfuerzo por evitar los hilos y preferir
procesos independientes, quizás con pasaje de mensajes, para evitar los
problemas de lidiar con estado mutable concurrente.

En lenguajes funcionales como Haskell o Erlang, es muchísimo más fácil
escribir programas concurrentes usando hilos, porque es imposible tener
estado mutable "vulnerable": en el caso de Erlang, porque tienes que
pasar mensajes entre estados inmutables independientes; en el caso de
Haskell, porque puedes usar Memoria Transaccional (STM) garantizada por
el sistema de tipos.

La primera técnica la puedes simular en Perl, usando el módulo
Parallel::ForkManager y algún IPC inmutable (pipes, sockets). La segunda
técnica no se puede simular *completamente* en un lenguaje imperativo
moderno, y es poco probable que se logre porque el costo de implantación
y ejecución es enorme por muchas razones técnicas.

La programación concurrente y paralela es mucho más práctica y amena en
lenguajes funcionales.
-- 
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1