Otra pregunta en varios idiomas: ¿alguien puede decirme qué construcciones de C# Threading coinciden mejor con las clases Java ReentrantLock y Condition? ReentrantLock ha bloqueado los métodos Interruptibly() y unlock(), mientras que Condition tiene los métodos signal() y await(). Es esta combinación la que me gustaría poder conservar en el código C#, o algo similar ... Gracias de antemano.¿La mejor coincidencia en C# con Java ReentrantLock y condición?
Creo que lo que estás buscando es la clase estática Monitor. Permite la adquisición de mutex blocking y non-blocking, así como las operaciones condition variable. (Los llaman Pulse, PulseAll y Wait en lugar de la señal y esperan).
DESCARGO DE RESPONSABILIDAD: No conozco estas clases de Java, estoy dando una estocada en la oscuridad aquí.
En C#, tiene una instrucción lock (creo que esto es algo así como la declaración de synchronized de Java) que puede bloquearse en cualquier objeto. Supongo que usar esa declaración, o Monitor.Enter(obj) y Monitor.Exit(obj) sería un poco como ReentrantLock.
Hay dos clases llamadas ManualResetEvent y AutoResetEvent. Estas clases tienen un método Wait y un método Set, que supongo que es como la señal de Condition y esperan. La diferencia entre estas dos clases es que se mantiene establecido un ManualResetEvent (ya no bloquea a nadie) y debe ser Reset. Y AutoResetEvent es, como su nombre indica, restablecer automáticamente.
No se puede usar el bloqueo en la sentencia async y se debe llamar a los métodos del Monitor desde el hilo sincronizado ... el punto de ReentrantLock de Java es hacer que esos problemas desaparezcan. – Vistritium
Al ver que los métodos de sincronización no existían ni en C# ni en Java cuando se formuló esta pregunta, creo que ese no es el punto de ReentrantLock, o al menos no el punto al que se refería el autor de la pregunta. – configurator
La clase ReaderWriterLock también valdría la pena investigar. Esto es similar a ReentrantReadWriteLock en Java.
+1 para señalar la similitud. Pero MSDN recomienda usar [ReaderWriterLockSlim] (https://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx) sobre 'ReaderWriterLock'. – NightOwl888
Parece que está trabajando para mí! ¡Gracias! Otra pregunta: ¿proporciona Monitor una contraparte de Java isHeldByCurrentThread()? –
No, podría extender Monitor y mantener una referencia al subproceso que finalmente llamó exitosamente Enter o TryEnter. Se puede acceder al hilo actual usando Thread.CurrentThread: http://msdn.microsoft.com/en-us/library/system.threading.thread.currentthread.aspx –