2012-03-08 9 views
9

Necesito armar un sistema concurrente con un Control.Concurrent.Chan compartido entre subprocesos. Solo habrá un consumidor y muchos productores. Al mirar Chan documentation no vi ninguna advertencia sobre la cantidad de consumidores y productores que pueden funcionar en el mismo canal, y el código fuente parece estar utilizando los accesos "seguros" predeterminados para MVar s, por lo tanto, creo que debería ser seguro suponer que no debería haber limitaciones, pero no estoy seguro. Entonces, mi pregunta es ... ¿sabes si los canales haskell son seguros (en general) para múltiples lectores y productores, por favor?¿Los canales de Haskell `Control.Concurrent.Chan` son seguros para múltiples lectores/productores?

Respuesta

11

Son seguros para cualquier cantidad de hilos. Son una simple lista vinculada basada en MVar. Las compensaciones de diseño permiten dupChan, que ayudan en el caso opuesto de transmisión a múltiples lectores.

El Chan es tan simple que no cuenta el número de elementos que contiene, ni tiene un límite superior. Entonces, si los productores superan al consumidor, entonces el Chan será muy grande. Si esto es un problema, puede emparejar el Chan con un (MVar Int). y hacer que los productores y consumidores modifiquen el total acumulado de elementos en el Chan.

+0

Bien, gracias. La ausencia de un límite superior no es un problema en mi caso, porque cada hilo enviará un solo mensaje una vez completado. Es una estructura simple que voy a usar para que el hilo principal espere N mensajes (si N es el número de hilos) del canal antes de continuar. –

+0

Una barrera contada como esta se ve como un semáforo en cantidad, puede reemplazar la longitud de la lista enlazada del Chan con MSem o MSemN en http://hackage.haskell.org/package/SafeSemaphore usando una cantidad inicial de (1-N). –

+0

No sabía sobre semáforos en la plataforma de haskell, muchas gracias por señalarlo. Reemplazaré los canales con ellos de seguro. –

Cuestiones relacionadas