¿Hay un bloqueo delgado de lector/escritor para .NET 2.0?

Question

He visto el ReaderWriterLock en .NET 2.0 y el ReaderWriterLockSlim en .NET 3.5, y la versión delgada no usa objetos del kernel para el bloqueo. Para mi contexto, que potencialmente puede generar una cantidad grande (pero no enorme) de objetos, esto suena mejor.

Pero el código que escribo debe usarse tanto en .NET 2.0 como en 3.5 durante un período de transición, por lo que la versión 3.5, aunque se ve bien para mis propósitos, no se puede usar.

¿Alguien tiene, o conoce, una clase similar que puedo conectar a .NET 2.0 y obtener algunos de los mismos beneficios?

Answer 1

Por lo que yo sé que no es uno de Microsoft (de lo contrario ReaderWriterLockSlim sería algo inútil) y si encuentro uno de un tercero que no sea uno de su confianza que tienen excelentes mentes que han pasado mucho tiempo pensando, implementando y probando, no confiaría en eso. Ciertamente no confiaría en una implementación aleatoria de CodeProject, por ejemplo.

¿Tiene alguna medida concreta para sugerir que el uso de ReaderWriterLockSlim sería tan mucho mejor que vale la pena mirar duro de alternativas para .NET 2.0? Ciertamente, es "agradable de tener", pero sospecho que los casos en los que es masivamente significativo son relativamente raros. A menos que ya sepa que el bloqueo es un cuello de botella para usted, me quedaré con lo que tiene y simplemente estaré listo para actualizar cuando pueda.

Aunque tal vez quiera probar el uso de monitores normales en lugar de ReaderWriterLock, en muchos casos la sobrecarga de RWL supera el beneficio.

Por supuesto, es todo sobre una base caso por caso - su aplicación puede ser uno que realmente se hizo mucho, mucho más rápido por ReaderWriterLockSlim ...

Answer 2

¿Qué hay de ReaderWriterGate de la biblioteca PowerThreading?

Answer 3

No hard lock ReadWriteLocker - Esta clase está diseñada con la opción ReaderWriterLock, que es 20% -30% más rápida que ReaderWriterLock.

Las diferencias que he hecho son:

1. Soporta actualizar esclusas a través de bloqueos de escritura nido en el interior de leer cerraduras. A diferencia de ReaderWriterLock, los bloqueos de actualización son seguros para la ejecución de subprocesos.
2. Tiene colecciones de ejemplos que le muestran cómo diseñar colecciones seguras para hilos . No son tan eficientes como las colecciones PFX de .NET 4.0, pero tienen otros beneficios.
3. Can not Deadlock si todos los bloqueos que se inician están desbloqueados. Y ese todos los demás mecanismos de bloqueo se ejecutan mutuamente exclusivos para este casillero.
4. Capacidad para detectar interbloqueos y desactivar la tara de detección de interbloqueos, una vez que verifique que no se produzcan interbloqueos.
5. Muy recursivo, y muchas veces más robusto que ReaderWriterLock y ReaderWriterLockSlim.

he pasado mucho trabajo en él, y espero que resulta muy útil. Es muy nuevo, a partir de ahora, y se necesitarán pruebas con respecto a otros mecanismos de bloqueo. Y, por supuesto, todo es queja de .NET 2.0.

Answer 4

He hecho una pregunta acerca de las desventajas del uso de ReaderWriterLock y hay algunos enlaces interesantes que contienen alternativas a ReaderWriterLock. Eche un vistazo al answer to my question.