En realidad no es una cuestión de bloqueo, sino de lo que significa la referencia:
TVar
es una referencia mutable dentro STM
, que representa el estado general compartido. Usted lo crea manteniendo un valor, puede leer y escribir en él, etc. Es muy similar a IORef
o STRef
(que son lo mismo de todos modos).
TMVar
es una referencia a una ranura que los hilos pueden usar para comunicarse. Se puede crear manteniendo un valor, o vacío. Puedes ponerle un valor, que si ya está lleno de bloques hasta que alguien más lo vacíe; o puede tomar un valor de él, que si ya está vacío bloquea hasta que alguien lo llene. Es obviamente similar a un MVar
, pero para muchos usos comunes podría ser más simple pensar en él como una cola de elemento único utilizada para un par productor/consumidor comunicante.
En resumen, es TVar
estado compartido en general, lo utilizan si desea que las actualizaciones atómicas a los datos de lugares arbitrarios. TMVar
es una primitiva de sincronización, úsela si desea que un hilo espere hasta que algo esté disponible, mientras que otro espera que algo se necesite.
También tenga en cuenta TChan
, que se implementa más o menos como dos TVar
s sostienen lugares en una lista enlazada donde cada enlace directo es también un TVar
, y trabaja como una cola sin límites para la comunicación.
Todos estos se pueden utilizar de maneras ligeramente diferentes, por supuesto, puede echar un vistazo al valor de TMVar
sin eliminarlo, por ejemplo, si desea un escenario en el que varios subprocesos esperen un único recurso para estar disponible, pero nunca se "agota". no duda comparable a las diferencias entre IORef
y MVar
-
¿Cómo '' volver a intentar 'causar interbloqueos?Reduce la transacción actual, luego bloquea hasta que la situación cambie de alguna manera. No (de hecho, no puede) bloquear dentro de una transacción. –
Aunque no se estancará en el medio de una transacción, se pueden crear transacciones que nunca pueden tener éxito de una manera similar a cómo se crean los interbloqueos clásicos, como dos transacciones que esperan los resultados de los demás. No es inmediatamente obvio cómo esto es diferente del punto muerto en la práctica. – Rotsor
Ah, a la derecha. Creo que el término real para eso es, apropiadamente, "livelock". Sin embargo, es más una especie de inanición de recursos que un punto muerto. Mientras que los bloqueos pueden resultar fácilmente de usos no relacionados de los mismos recursos, creo que la naturaleza optimista de STM hace improbables los bloqueos a menos que exista un conflicto directo o una contención general muy alta. –