Control de concurrencia

En tecnología de la información y ciencias de la computación, especialmente en los campos de programación de computadoras, sistemas operativos, multiprocesadores y bases de datos, el control de concurrencia garantiza que se generen resultados correctos para operaciones concurrentes, mientras se obtienen esos resultados lo más rápido posible..

Los sistemas informáticos, tanto de software como de hardware, constan de módulos o componentes. Cada componente está diseñado para operar correctamente, es decir, obedecer o cumplir con ciertas reglas de consistencia. Cuando los componentes que operan simultáneamente interactúan mediante mensajes o compartiendo datos a los que se accede (en la memoria o en el almacenamiento), otro componente puede violar la consistencia de un determinado componente. El área general de control de concurrencia proporciona reglas, métodos, metodologías de diseño y teorías para mantener la consistencia de los componentes que operan simultáneamente mientras interactúan y, por lo tanto, la consistencia y corrección de todo el sistema. Introducir el control de concurrencia en un sistema significa aplicar restricciones de operación que típicamente resultan en una reducción del rendimiento. La consistencia y la corrección de la operación deben lograrse con la mayor eficiencia posible, sin reducir el rendimiento por debajo de niveles razonables. El control de concurrencia puede requerir una complejidad y una sobrecarga adicionales significativas en un algoritmo concurrente en comparación con el algoritmo secuencial más simple.

Por ejemplo, una falla en el control de concurrencia puede resultar en la corrupción de datos debido a operaciones de lectura o escritura rotas.

Control de concurrencia en bases de datos

Comentarios:

1. Esta sección es aplicable a todos los sistemas transaccionales, es decir, a todos los sistemas que utilizan transacciones de bases de datos ()transacciones atómicas; por ejemplo, objetos transaccionales en la gestión de sistemas y en redes de teléfonos inteligentes que normalmente implementan sistemas de bases de datos privados y dedicados, no sólo sistemas de gestión de bases de datos para fines generales (DBMSs).
2. Los DBMS también deben tratar cuestiones de control de la concurrencia no típicas sólo de las transacciones de bases de datos sino más bien de los sistemas operativos en general. Estos temas (por ejemplo, ver Control de concurrencia en sistemas operativos infra) están fuera del alcance de esta sección.

El control de concurrencia en los sistemas de administración de bases de datos (DBMS; p. ej., Bernstein et al. 1987, Weikum y Vossen 2001), otros objetos transaccionales y aplicaciones distribuidas relacionadas (p. ej., Grid Computing y Cloud Computing) garantiza que las transacciones de bases de datos se realizan simultáneamente sin violar la integridad de los datos de las respectivas bases de datos. Por lo tanto, el control de concurrencia es un elemento esencial para la corrección en cualquier sistema donde dos transacciones de base de datos o más, ejecutadas con superposición de tiempo, pueden acceder a los mismos datos, por ejemplo, virtualmente en cualquier sistema de base de datos de propósito general. En consecuencia, se ha acumulado una gran cantidad de investigaciones relacionadas desde que surgieron los sistemas de bases de datos a principios de la década de 1970. Una teoría de control de concurrencia bien establecida para los sistemas de bases de datos se describe en las referencias mencionadas anteriormente: la teoría de la serialización, que permite diseñar y analizar eficazmente los métodos y mecanismos de control de concurrencia. Una teoría alternativa para el control de concurrencia de transacciones atómicas sobre tipos de datos abstractos se presenta en (Lynch et al. 1993), y no se utiliza a continuación. Esta teoría es más refinada, compleja, con un alcance más amplio y ha sido menos utilizada en la literatura de bases de datos que la teoría clásica anterior. Cada teoría tiene sus pros y sus contras, énfasis y perspicacia. Hasta cierto punto son complementarios y su fusión puede ser útil.

Para garantizar la corrección, un DBMS generalmente garantiza que solo se generen programaciones de transacciones serializables, a menos que la capacidad de serialización se relaje intencionalmente para aumentar el rendimiento, pero solo en los casos en que la aplicación sea correcta. no dañado Para mantener la corrección en casos de transacciones fallidas (abortadas) (lo que siempre puede suceder por muchas razones), los horarios también deben tener la propiedad recuperabilidad (de abortar). Un DBMS también garantiza que no se pierda ningún efecto de las transacciones comprometidas, y que no permanezca ningún efecto de las transacciones abortadas (revertidas) en la base de datos relacionada. La caracterización general de la transacción generalmente se resume mediante las reglas ACID a continuación. A medida que las bases de datos se distribuyeron o se necesitaron para cooperar en entornos distribuidos (por ejemplo, las bases de datos federadas a principios de 1990 y la computación en la nube en la actualidad), la distribución efectiva de los mecanismos de control de concurrencia ha recibido especial atención.

Transacción de base de datos y reglas ACID

El concepto de una transacción de base de datos (o transacción atómica) ha evolucionado para permitir un comportamiento bien entendido del sistema de base de datos en un entorno defectuoso donde pueden ocurrir fallas en cualquier momento. tiempo y recuperación de un bloqueo a un estado de base de datos bien entendido. Una transacción de base de datos es una unidad de trabajo, que normalmente encapsula una serie de operaciones sobre una base de datos (por ejemplo, leer un objeto de base de datos, escribir, adquirir un bloqueo, etc.), una abstracción admitida en la base de datos y también en otros sistemas. Cada transacción tiene límites bien definidos en términos de qué ejecuciones de programa/código se incluyen en esa transacción (determinado por el programador de la transacción a través de comandos de transacción especiales). Cada transacción de base de datos obedece las siguientes reglas (por soporte en el sistema de base de datos; es decir, un sistema de base de datos está diseñado para garantizarlas para las transacciones que ejecuta):

• Atomicity - O los efectos de todas o ninguna de sus operaciones permanecen ("toda o nada" semántica) cuando se completa una transacción (comprometidos o abortado respectivamente). En otras palabras, al mundo exterior aparece una transacción comprometida (por sus efectos en la base de datos) indivisible (atómica), y una transacción abortada no afecta en absoluto a la base de datos. O todas las operaciones se realizan o ninguna de ellas.
• Consistencia - Cada transacción debe salir de la base de datos en un estado consistente (correcto), es decir, mantener las reglas de integridad predeterminadas de la base de datos (constrictas sobre los objetos de la base de datos y entre ellos). Una transacción debe transformar una base de datos de un estado consistente a otro estado consistente (cuando sea, es responsabilidad del programador de la transacción asegurarse de que la transacción misma sea correcta, es decir, realiza correctamente lo que pretende realizar (desde el punto de vista de la aplicación) mientras que las reglas de integridad predefinidas son aplicadas por el DBMS). Así pues, dado que una base de datos puede cambiarse normalmente sólo por transacciones, todos los estados de la base de datos son consistentes.
• Solución - Las transacciones no pueden interferir entre sí (como resultado final de sus ejecuciones). Además, generalmente (dependiendo del método de control de concurrencia) los efectos de una transacción incompleta ni siquiera son visibles a otra transacción. El aislamiento es el objetivo principal del control de la concurrencia.
• Durabilidad - Los efectos de las transacciones exitosas (comprometidas) deben persistir a través de fallos (normalmente grabando los efectos de la transacción y su evento de compromiso en una memoria no volátil).

El concepto de transacción atómica se ha extendido durante los años a lo que se ha convertido en transacciones comerciales que en realidad implementan tipos de flujo de trabajo y no son atómicas. Sin embargo, tales transacciones mejoradas también utilizan típicamente transacciones atómicas como componentes.

¿Por qué es necesario el control de concurrencia?

Si las transacciones se ejecutan en serie, es decir, secuencialmente sin superposición en el tiempo, no existe concurrencia de transacciones. Sin embargo, si se permiten transacciones concurrentes con operaciones de entrelazado de manera no controlada, pueden ocurrir algunos resultados inesperados e indeseables, tales como:

1. El problema de actualización perdido: Una segunda transacción escribe un segundo valor de un data-item (datum) sobre un primer valor escrito por una primera transacción concurrente, y el primer valor se pierde a otras transacciones concurrentes que necesitan, por su precedencia, leer el primer valor. Las transacciones que han leído el valor incorrecto final con resultados incorrectos.
2. El problema de lectura sucia: Las transacciones leen un valor escrito por una transacción que luego ha sido abortada. Este valor desaparece de la base de datos al abortar, y no debería haber sido leído por ninguna transacción ("leer sucia"). Las transacciones de lectura terminan con resultados incorrectos.
3. El problema sumario incorrecto: Si bien una transacción toma un resumen sobre los valores de todos los casos de un repetido punto de datos, una segunda transacción actualiza algunos casos de ese punto de datos. El resumen resultante no refleja un resultado correcto para ninguna orden de precedencia (generalmente necesaria para la corrección) entre las dos transacciones (si se ejecuta antes del otro), sino más bien algún resultado aleatorio, dependiendo del momento de las actualizaciones, y si ciertos resultados de actualización se han incluido en el resumen o no.

La mayoría de los sistemas transaccionales de alto rendimiento necesitan ejecutar transacciones simultáneamente para cumplir con sus requisitos de rendimiento. Por lo tanto, sin control de concurrencia, estos sistemas no pueden proporcionar resultados correctos ni mantener sus bases de datos de manera consistente.

Mecanismos de control de concurrencia

Categorías

Las principales categorías de mecanismos de control de concurrencia son:

• Optimistic - Reducir la comprobación de si una transacción cumple con las reglas de aislamiento y de integridad (por ejemplo, serializabilidad y recuperabilidad) hasta su final, sin bloquear ninguna de sus operaciones (leer, escribir) ("...y ser optimista sobre las reglas que se están cumpliendo..."), y luego abortar una transacción para prevenir la violación, si las reglas deseadas son violadas en su compromiso. Una transacción abortada es inmediatamente reiniciada y ejecutada, que incurre en una sobrecarga obvia (versus ejecution it to the end only once). Si no se abortan demasiadas transacciones, entonces ser optimista es generalmente una buena estrategia.
• Pesimistic - Bloquear una operación de una transacción, si puede causar violación de las reglas, hasta que la posibilidad de violación desaparece. Las operaciones de bloqueo suelen estar relacionadas con la reducción del rendimiento.
• Semioptimistic - Bloquear operaciones en algunas situaciones, si pueden causar violación de algunas reglas, y no bloquear en otras situaciones, al tiempo que retrasar las reglas de verificación (si es necesario) al final de la transacción, como se hace con optimista.

Diferentes categorías proporcionan un rendimiento diferente, es decir, diferentes tasas promedio de finalización de transacciones (rendimiento), según la combinación de tipos de transacciones, el nivel informático de paralelismo y otros factores. Si se dispone de selección y conocimiento sobre las ventajas y desventajas, entonces la categoría y el método deben elegirse para proporcionar el mayor rendimiento.

El bloqueo mutuo entre dos transacciones (donde cada una bloquea a la otra) o más da como resultado un interbloqueo, donde las transacciones involucradas se estancan y no pueden completarse. La mayoría de los mecanismos no optimistas (con bloqueo) son propensos a interbloqueos que se resuelven mediante un aborto intencional de una transacción estancada (que libera las otras transacciones en ese interbloqueo), y su reinicio y reejecución inmediatos. La probabilidad de un interbloqueo suele ser baja.

El bloqueo, los interbloqueos y las anulaciones dan como resultado una reducción del rendimiento y, por lo tanto, las compensaciones entre las categorías.

Métodos

Existen muchos métodos para el control de concurrencia. La mayoría de ellos se pueden implementar dentro de cualquiera de las categorías principales anteriores. Los principales métodos, que tienen muchas variantes y, en algunos casos, pueden superponerse o combinarse, son:

1. Cierre (por ejemplo, Locking de dos fases - 2PL) - Controlar el acceso a los datos mediante cerraduras asignadas a los datos. El acceso de una transacción a un elemento de datos (objeto de base de datos) bloqueado por otra transacción puede ser bloqueado (según tipo de bloqueo y tipo de operación de acceso) hasta la liberación de bloqueo.
2. Verificación de gráficos en serie (también llamada Serializability, o Conflicto, o comprobación de gráficos de Precedencia) - Comprobando ciclos en el gráfico del programa y rompiéndolos por abortos.
3. Ordenación de horarios (TO) - Asignar plazos a transacciones, y controlar o verificar el acceso a datos por orden de tiempo.
4. Ordenación del compromiso (o Commit ordering; CO) - Controlar o verificar el orden cronológico de los eventos de compromiso para ser compatible con su orden de precedencia respectiva.

Otros tipos principales de control de concurrencia que se utilizan junto con los métodos anteriores incluyen:

• Control de concurrencia de multiversión (MVCC) - Aumentar la concurrencia y el rendimiento generando una nueva versión de un objeto de base de datos cada vez que el objeto está escrito, y permitiendo operaciones de lectura de transacciones de varias últimas versiones relevantes (de cada objeto) dependiendo del método de programación.
• Control de la moneda - Sincronizar las operaciones de acceso a los índices, en lugar de a los datos del usuario. Los métodos especializados proporcionan importantes beneficios de rendimiento.
• Modelo de espacio de trabajo privado ()Actualización diferida) - Cada transacción mantiene un espacio de trabajo privado para sus datos accedidos, y sus datos cambiados se vuelven visibles fuera de la transacción sólo cuando se compromete (por ejemplo, Weikum y Vossen 2001). Este modelo proporciona un comportamiento de control de concurrencia diferente con beneficios en muchos casos.

El tipo de mecanismo más común en los sistemas de bases de datos desde sus inicios en la década de 1970 ha sido Bloqueo en dos fases estricto y fuerte (SS2PL; también llamado Programación rigurosa o Rigurous 2PL), que es un caso especial (variante) tanto del bloqueo de dos fases (2PL) como del pedido de compromiso (CO). es pesimista. A pesar de su nombre largo (por razones históricas), la idea del mecanismo SS2PL es simple: "Libere todos los bloqueos aplicados por una transacción solo después de que la transacción haya finalizado." SS2PL (o Rigurosidad) es también el nombre del conjunto de todos los cronogramas que pueden ser generados por este mecanismo, es decir, estos cronogramas SS2PL (o Rigurosidad) tienen la propiedad SS2PL (o Rigurosidad).

Objetivos principales de los mecanismos de control de concurrencia

Los mecanismos de control de concurrencia primero deben funcionar correctamente, es decir, mantener las reglas de integridad de cada transacción (en relación con la concurrencia; las reglas de integridad específicas de la aplicación están fuera del alcance aquí) mientras las transacciones se ejecutan simultáneamente y, por lo tanto, la integridad de todo el sistema transaccional. La corrección debe lograrse con el mejor rendimiento posible. Además, existe una necesidad cada vez mayor de operar con eficacia mientras las transacciones se distribuyen entre procesos, computadoras y redes informáticas. Otros temas que pueden afectar el control de concurrencia son la recuperación y la replicación.

Corrección

Serializabilidad

Para la corrección, un objetivo principal común de la mayoría de los mecanismos de control de concurrencia es generar programaciones con la propiedad Serializabilidad. Sin serialización, pueden ocurrir fenómenos indeseables, por ejemplo, el dinero puede desaparecer de las cuentas o generarse de la nada. Serializabilidad de un cronograma significa equivalencia (en los valores de la base de datos resultantes) a algún cronograma serial con las mismas transacciones (es decir, en el que las transacciones son secuenciales sin superposición en el tiempo, y por lo tanto, completamente aislados entre sí: no es posible el acceso simultáneo de dos transacciones cualesquiera a los mismos datos). La serialización se considera el nivel más alto de aislamiento entre las transacciones de bases de datos y el principal criterio de corrección para transacciones concurrentes. En algunos casos, se permiten formas comprometidas y relajadas de serialización para un mejor rendimiento (por ejemplo, el popular mecanismo de aislamiento de instantáneas) o para cumplir con los requisitos de disponibilidad en sistemas altamente distribuidos (consulte Coherencia eventual), pero solo si la relajación no viola la corrección de la aplicación (por ejemplo, no se permite la relajación para las transacciones de dinero, ya que mediante la relajación el dinero puede desaparecer o aparecer de la nada).

Casi todos los mecanismos de control de concurrencia implementados logran serializabilidad al proporcionar Serializabilidad de conflicto, un caso especial amplio de serializabilidad (es decir, cubre, habilita la mayoría de los horarios serializables y no impone restricciones adicionales significativas que causen retrasos).) que se pueden implementar de manera eficiente.

Recuperabilidad

See Recoverability dentro Serializability

Comentario: Mientras que en el área general de sistemas el término "recuperabilidad" puede referirse a la capacidad de un sistema para recuperarse de una falla o de un estado incorrecto/prohibido, dentro del control de concurrencia de los sistemas de bases de datos, este término ha recibido un significado específico.

El control de concurrencia generalmente también asegura la propiedad Recuperabilidad de los horarios para mantener la corrección en casos de transacciones abortadas (lo que siempre puede suceder por muchas razones). Recuperabilidad (de anulación) significa que ninguna transacción confirmada en una programación ha leído datos escritos por una transacción anulada. Dichos datos desaparecen de la base de datos (al abortar) y son parte de un estado de base de datos incorrecto. La lectura de dichos datos infringe la regla de coherencia de ACID. A diferencia de la capacidad de serialización, la capacidad de recuperación no se puede comprometer, relajar en ningún caso, ya que cualquier relajación da como resultado una violación rápida de la integridad de la base de datos en caso de abortos. Los principales métodos enumerados anteriormente proporcionan mecanismos de serialización. Ninguno de ellos en su forma general proporciona recuperabilidad automáticamente, y se necesitan consideraciones especiales y mejoras en el mecanismo para respaldar la recuperabilidad. Un caso especial de recuperabilidad comúnmente utilizado es Strictness, que permite una recuperación eficiente de la base de datos de fallas (pero excluye implementaciones optimistas; por ejemplo, Strict CO (SCO) no puede tener una implementación optimista, pero tiene semi-optimistas).

Comentario: Tenga en cuenta que la propiedad Recuperabilidad es necesaria incluso si no se produce un error en la base de datos y no se necesita una recuperación de la base de datos del error. Más bien, es necesario para manejar correctamente los abortos de transacciones, que pueden no estar relacionados con la falla de la base de datos y la recuperación de la misma.

Distribución

Con el rápido desarrollo tecnológico de la informática, la diferencia entre la informática local y la distribuida a través de redes o buses de baja latencia se está difuminando. Por lo tanto, la utilización bastante efectiva de técnicas locales en dichos entornos distribuidos es común, por ejemplo, en clústeres de computadoras y procesadores de múltiples núcleos. Sin embargo, las técnicas locales tienen sus limitaciones y utilizan multiprocesos (o subprocesos) compatibles con multiprocesadores (o multinúcleos) para escalar. Esto a menudo convierte las transacciones en transacciones distribuidas, si ellas mismas necesitan abarcar múltiples procesos. En estos casos, la mayoría de las técnicas de control de concurrencia local no escalan bien.

Serialización distribuida y orden de compromiso

See Distribuida serializability dentro Serializability

A medida que los sistemas de bases de datos se distribuyeron o comenzaron a cooperar en entornos distribuidos (por ejemplo, las bases de datos federadas a principios de la década de 1990 y, en la actualidad, la computación en cuadrícula, la computación en la nube y las redes con teléfonos inteligentes), algunas transacciones se distribuyeron. Una transacción distribuida significa que la transacción abarca procesos y puede abarcar computadoras y sitios geográficos. Esto genera una necesidad de mecanismos efectivos de control de concurrencia distribuida. Lograr la propiedad Serializabilidad de la programación de un sistema distribuido (consulte Serializabilidad distribuida y Serializabilidad global (Serializabilidad modular)) plantea desafíos especiales de manera efectiva. normalmente no se cumple con la mayoría de los mecanismos regulares de serialización, originalmente diseñados para operar localmente. Esto se debe especialmente a la necesidad de una distribución costosa de la información de control de concurrencia en medio de la latencia informática y de comunicación. La única técnica eficaz general conocida para la distribución es el pedido de compromiso, que se hizo público en 1991 (después de ser patentado). Commitment ordering (Commit ordering, CO; Raz 1992) significa que las transacciones' el orden cronológico de los eventos de confirmación se mantiene compatible con su respectivo orden de precedencia. CO no requiere la distribución de información de control de concurrencia y proporciona una solución general efectiva (confiable, de alto rendimiento y escalable) tanto para la serialización distribuida como global, también en un entorno heterogéneo con sistemas de bases de datos (u otros objetos transaccionales) con diferentes (cualquiera) mecanismos de control de concurrencia. CO es indiferente a qué mecanismo se utiliza, ya que no interfiere con la programación de ninguna operación de transacción (que la mayoría de los mecanismos controlan) y solo determina el orden de los eventos de confirmación. Por lo tanto, CO permite la distribución eficiente de todos los demás mecanismos, y también la distribución de una combinación de diferentes (cualquier) mecanismo local, para lograr serialización distribuida y global. La existencia de tal solución se ha considerado "poco probable" hasta 1991, y por muchos expertos también más tarde, debido a la falta de comprensión de la solución de CO (ver Citas en Serializabilidad global). Un beneficio secundario importante de CO es la resolución automática de interbloqueos distribuidos. A diferencia de CO, prácticamente todas las demás técnicas (cuando no se combinan con CO) son propensas a interbloqueos distribuidos (también llamados interbloqueos globales) que necesitan un manejo especial. CO es también el nombre de la propiedad de programación resultante: una programación tiene la propiedad CO si el orden cronológico de sus transacciones' commit events es compatible con las transacciones respectivas' orden de precedencia (parcial).

SS2PL mencionado anteriormente es una variante (caso especial) de CO y, por lo tanto, también es eficaz para lograr serialización global y distribuida. También proporciona resolución automática de interbloqueos distribuidos (un hecho pasado por alto en la literatura de investigación incluso después de la publicación de CO), así como Rigurosidad y, por lo tanto, Recuperabilidad. La posesión de estas propiedades deseadas junto con implementaciones basadas en bloqueo eficientes conocidas explica la popularidad de SS2PL. SS2PL se ha utilizado para lograr serialización global y distribuida de manera eficiente desde 1980, y se ha convertido en el estándar de facto para ello. Sin embargo, SS2PL bloquea y restringe (pesimista), y con la proliferación de distribución y utilización de sistemas diferentes de los sistemas de bases de datos tradicionales (p. ej., como en la computación en la nube), se pueden necesitar tipos de CO menos restrictivos (p. ej., CO optimista) para mejor interpretación.

Comentarios:

1. El Distribuido conflicto serializability la propiedad en su forma general es difícil de lograr de manera eficiente, pero se logra eficientemente a través de su caso especial Distribuido CO: Cada componente local (por ejemplo, un DBMS local) necesita tanto para proporcionar alguna forma de CO, como para hacer cumplir una estrategia de orden de voto para el Protocolo de compromiso de dos fases (2PC: utilizado para realizar transacciones distribuidas). Diferentemente del CO distribuida general, Distribuida SS2PL existe automáticamente cuando todos los componentes locales están basados en SS2PL (en cada componente CO existe, implicado, y la estrategia de orden de voto se cumple automáticamente). Este hecho ha sido conocido y utilizado desde la década de 1980 (es decir, que SS2PL existe globalmente, sin saber sobre CO) para eficiente SS2PL distribuida, lo que implica serializabilidad y rigor distribuidos (por ejemplo, véase Raz 1992, página 293; también está implicado en Bernstein et al. 1987, página 78). Menos limitada La serializabilidad y la rigidez distribuidas pueden lograrse de manera eficiente gracias a Distribuido Strict CO (SCO), o mediante una mezcla de componentes locales basados en SS2PL y SCO.
2. Sobre las referencias y la Orden de Compromiso: (Bernstein et al. 1987) se publicó antes del descubrimiento del CO en 1990. La propiedad programada de CO se llama Atómica dinámica in (Lynch et al. 1993, pág. 201). El CO se describe en (Weikum y Vossen 2001, páginas 102, 700), pero la descripción es parcial y falta la esencia del CO. (Raz 1992) fue la primera referencia y aceptada para publicación artículo sobre algoritmos de CO (cuando sea, las publicaciones sobre una propiedad equivalente de atomicidad dinámica se pueden rastrear a 1988). Se siguieron otros artículos de CO. (Bernstein y Newcomer 2009) nota CO como uno de los cuatro métodos principales de control de concurrencia, y la capacidad de CO para proporcionar interoperabilidad entre otros métodos.

Recuperabilidad distribuida

A diferencia de la Serializabilidad, la Recuperabilidad distribuida y la Estrictez distribuida se pueden lograr de manera eficiente y sencilla, de manera similar a como se logra el CO distribuido: en cada sistema de base de datos tienen que aplicarse localmente y emplear una estrategia de ordenamiento de votos para el protocolo de confirmación en dos fases (2PC; Raz 1992, página 307).

Como se mencionó anteriormente, el SS2PL distribuido, que incluye el rigor distribuido (recuperabilidad) y el orden de compromiso distribuido (capacidad de serialización), emplea automáticamente la estrategia de orden de votos necesaria y se logra (globalmente) cuando se emplea localmente en cada sistema de base de datos (local). (como se ha conocido y utilizado durante muchos años; de hecho, la localidad se define por el límite de un participante de 2PC (Raz 1992)).

Recuperación

Todos los sistemas son propensos a fallar, y el manejo de la recuperación de una falla es imprescindible. Las propiedades de los programas generados, que son dictados por el mecanismo de control de concurrencia, pueden afectar la eficacia y la eficiencia de la recuperación. Por ejemplo, la propiedad Rigurosidad (mencionada en la sección anterior Capacidad de recuperación) suele ser deseable para una recuperación eficiente.

Replicación

Para una base de datos de alta disponibilidad, los objetos a menudo se replican. Las actualizaciones de réplicas de un mismo objeto de base de datos deben mantenerse sincronizadas. Esto puede afectar la forma en que se realiza el control de concurrencia (p. ej., Gray et al. 1996).

Véase también

• Cuadro
• Aislamiento (ciencia informática)
• Control de concurrencia distribuido

Referencias

• Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (1987): Concurrency Control and Recovery in Database Systems (free PDF download), Addison Wesley Publishing Company, 1987, ISBN 0-201-10715-5
• Gerhard Weikum, Gottfried Vossen (2001): Transactional Information Systems, Elsevier, ISBN 1-55860-508-8
• Nancy Lynch, Michael Merritt, William Weihl, Alan Fekete (1993): Atomic Transactions in Concurrent and Distributed Systems Morgan Kaufmann (Elsevier), agosto de 1993, ISBN 978-1-55860-104-8, ISBN 1-55860-104-X
• Yoav Raz (1992): "El Principio de Ordenación de Compromiso, o Garantía de Serializabilidad en un Medio Ambiente Heterogéneo de Múltiples Administradores de Recursos Autónomos Usando Compromiso Atómico." (PDF), Proceedings of the Eighteenth International Conference on Very Large Data Bases (VLDB), págs. 292 a 312, Vancouver, Canadá, agosto de 1992. (también DEC-TR 841, Digital Equipment Corporation, noviembre de 1990)

Citas

Control de concurrencia en sistemas operativos

Los sistemas operativos multitarea, especialmente los sistemas operativos en tiempo real, deben mantener la ilusión de que todas las tareas que se ejecutan sobre ellos se ejecutan al mismo tiempo, aunque solo una o unas pocas tareas se estén ejecutando en un momento dado. debido a las limitaciones del hardware en el que se ejecuta el sistema operativo. Tal multitarea es bastante simple cuando todas las tareas son independientes entre sí. Sin embargo, cuando varias tareas intentan usar el mismo recurso, o cuando las tareas intentan compartir información, puede generar confusión e inconsistencia. La tarea de la computación concurrente es resolver ese problema. Algunas soluciones implican "bloqueos" similares a los bloqueos utilizados en las bases de datos, pero corren el riesgo de causar sus propios problemas, como interbloqueos. Otras soluciones son algoritmos sin bloqueo y lectura-copia-actualización.

Véase también

• Linearizabilidad – Propiedad de algunas operaciones en programación simultánea
• Bloqueo (ciencia informática) – Mecanismo de sincronización para hacer cumplir los límites del acceso a un recurso
• Exclusión mutua – Al calcular, restringir los datos para ser accesibles por un hilo a la vez
• Indización del motor de búsqueda – procesamiento y almacenamiento de datos para permitir consultas de información rápidaPáginas que muestran descripciones de wikidata como retroceso
• Semaforo (programación) – Variable utilizado en un sistema concurrente
• Memoria transaccional del software – mecanismo de control de concurrencia para controlar el acceso a la memoria compartida en computación simultáneaPáginas que muestran descripciones de wikidata como retroceso
• Extensiones de sincronización transaccional – Ampliación a la arquitectura del conjunto de instrucciones x86 que agrega soporte de memoria transaccional hardware

Referencias

• Andrew S. Tanenbaum, Albert S Woodhull (2006): Diseño e implementación de sistemas operativos, 3a edición, Prentice Hall, ISBN 0-13-142938-8
• Silberschatz, Avi; Galvin, Peter; Gagne, Greg (2008). Conceptos de sistemas operativos, 8a edición. John Wiley & Sons. ISBN 978-0-470-12872-5.