Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Friday, March 23, 2007
PriorityReaderWriterFifoLock
El nombre de esta entrada es el lock de mis sueños.
Para quien no lo sepa, en .NET hay varias maneras de establecer regiones de exclusión mutua entre threads para que se bloqueen al acceder a ciertas zonas del flujo de código para evitar condiciones de carrera.
Últimamente en el curro tuve problemas con un bloque lock(){}, para acabar descubriendo que el sistema de espera de los threads bajo esa directiva no es FIFO, ni tampoco lo es la API de Semaphore, lo que puede dar problemas en caso de que tengamos cantidades ingentes de threads esperando (inanición).
Creo que lo he resuelto momentáneamente gracias al maravilloso PriorityLock, aunque aún así me surgen dudas de si realmente es una pila FIFO para los threads con prioridad de acceso equivalente (lo he puesto como pregunta en su "foro").
De aquí me viene la idea de PriorityReaderWriterFifoLock. Si algún día tengo tiempo, modificaré esta librería para, primero, asegurarme del tema del FIFO que ya he comentado y, segundo, añadir soporte de acceso n-lectores-OR-1-escritor a la vez que se respete el tema de las prioridades.
PD: Aprovecho la entrada para dar la enhorabuena a Néstor [ Wizito ] por su pedazo de proyecto de framework de componentes basado en Mono (aka Babuine). A ver cuándo puedo salir de este bache de tiempo-libre-cero y jugueteo un poco con ello ;)
Actualización 03-ABR-2007: Acojonantemente útil el método que propone Alan McGovern para utilizar los ReaderWriterLocks de manera que no tengamos la desventaja que se tenía frente al lock de poder introducir deadlocks debido a su distinta sintaxis de utilización.
Para quien no lo sepa, en .NET hay varias maneras de establecer regiones de exclusión mutua entre threads para que se bloqueen al acceder a ciertas zonas del flujo de código para evitar condiciones de carrera.
Últimamente en el curro tuve problemas con un bloque lock(){}, para acabar descubriendo que el sistema de espera de los threads bajo esa directiva no es FIFO, ni tampoco lo es la API de Semaphore, lo que puede dar problemas en caso de que tengamos cantidades ingentes de threads esperando (inanición).
Creo que lo he resuelto momentáneamente gracias al maravilloso PriorityLock, aunque aún así me surgen dudas de si realmente es una pila FIFO para los threads con prioridad de acceso equivalente (lo he puesto como pregunta en su "foro").
De aquí me viene la idea de PriorityReaderWriterFifoLock. Si algún día tengo tiempo, modificaré esta librería para, primero, asegurarme del tema del FIFO que ya he comentado y, segundo, añadir soporte de acceso n-lectores-OR-1-escritor a la vez que se respete el tema de las prioridades.
PD: Aprovecho la entrada para dar la enhorabuena a Néstor [ Wizito ] por su pedazo de proyecto de framework de componentes basado en Mono (aka Babuine). A ver cuándo puedo salir de este bache de tiempo-libre-cero y jugueteo un poco con ello ;)
Actualización 03-ABR-2007: Acojonantemente útil el método que propone Alan McGovern para utilizar los ReaderWriterLocks de manera que no tengamos la desventaja que se tenía frente al lock de poder introducir deadlocks debido a su distinta sintaxis de utilización.
Labels: CSharp, General, Mono, Programacion
# posted by knocte @ 11:19 am 
Comments:
<< Home
Espero no meterme donde no me llaman y no ser demasiado radical pero ¿No será que se cogen los locks durante demasiado tiempo? ¿No será que se debería usar un esquema más orientado al paso de mensajes?
Te comento esto porque me recuerda al caso de la resolución mágica de problemas con mutex recursivos, que no dejan de ser un hack. El esquema de bloqueos que propones, además de bonito :) , también me parece un poco hack...
Muy interesante entrada, por cierto :)
Un saludo
Te comento esto porque me recuerda al caso de la resolución mágica de problemas con mutex recursivos, que no dejan de ser un hack. El esquema de bloqueos que propones, además de bonito :) , también me parece un poco hack...
Muy interesante entrada, por cierto :)
Un saludo
Gracias por comentar la entrada.
En este caso concreto no creo que el tiempo de retención del lock sea la causa, pues sólo se usa durante el ámbito de uso de una variable (en concreto, de un Dictionary). Cualquier thread que quiere leer o escribir en la colección, usa un lock primero, y después de hacerlo, lo suelta.
Interesante lo de los mutex recursivos, pero tampoco he necesitado hacer uso de ellos de momento (afortunadamente ;)
En este caso concreto no creo que el tiempo de retención del lock sea la causa, pues sólo se usa durante el ámbito de uso de una variable (en concreto, de un Dictionary). Cualquier thread que quiere leer o escribir en la colección, usa un lock primero, y después de hacerlo, lo suelta.
Interesante lo de los mutex recursivos, pero tampoco he necesitado hacer uso de ellos de momento (afortunadamente ;)
Wee, muchas gracias por la enhorabuena Andrés :D
Ahora mi blog esta caido (mi server ha vuelto a morir) espero conseguir otro ya pronto :)
Ahora mi blog esta caido (mi server ha vuelto a morir) espero conseguir otro ya pronto :)
Realmente interesante pero... macho no escribes desde Marzo!, a ver si te pones las pilas y nos deleitas con algunos post hombre :-)
Post a Comment
# posted by 
: Friday, June 22, 2007 8:56:00 am
: Friday, June 22, 2007 8:56:00 am << Home
