Control de concurrencia

Ir a: navegación, búsqueda de

En tecnología de la información y Ciencias de la computación, especialmente en los campos de programación informática, sistemas operativos, multiprocesadores, y bases de datos, control de concurrencia asegura que corregir resultados para concurrente las operaciones se generan, al obtener esos resultados tan pronto como sea posible.

Sistemas informáticos, tanto software y hardware, consisten en módulos o componentes. Cada componente está diseñado para funcionar correctamente, es decir, las reglas para obedecer o para cumplir con cierta consistencia. Cuando los componentes que operan simultáneamente interactuan por mensajería o por compartir acceso a datos (en memoria o almacenamiento de información), consistencia de un determinado componente puede ser violado por otro componente. El área general del control de concurrencia proporciona reglas, métodos, metodologías de diseño, y teorías para mantener la consistencia de los componentes operando simultáneamente mientras interactúan y así la consistencia y la corrección de todo el sistema. Introducción control de concurrencia en un sistema significa aplicar restricciones de operación que generalmente resultan en una reducción del rendimiento. Corrección y consistencia de la operación se deben alcanzar con eficacia posible, sin reducir el rendimiento por debajo de unos niveles razonables. Control de simultaneidad puede requerir significativa complejidad adicional y gastos generales en un algoritmo concurrente Comparado con el más simple algoritmo secuencial.

Por ejemplo, puede ocasionar un fallo en el control de concurrencia corrupción de datos De leer rasgada o las operaciones de escritura.

Contenido

  • 1 Control de concurrencia en bases de datos
    • 1.1 Transacciones de bases de datos y las reglas ACID
    • 1.2 ¿Por qué es necesario el control de concurrencia.
    • 1.3 Mecanismos de control de concurrencia
      • 1.3.1 Categorías
      • 1.3.2 Métodos
    • 1.4 Objetivos principales de los mecanismos de control de concurrencia
      • 1.4.1 Corrección
        • 1.4.1.1 Serializabilidad
        • 1.4.1.2 Capacidad de recuperación
      • 1.4.2 Distribución
        • 1.4.2.1 Serializabilidad distribuido y compromiso ordenando
        • 1.4.2.2 Recuperación distribuida
      • 1.4.3 Otros temas importantes de la atención
        • 1.4.3.1 Recuperación
        • 1.4.3.2 Replicación
    • 1.5 Véase también
    • 1.6 Referencias
    • 1.7 Notas al pie
  • 2 Control de concurrencia en los sistemas operativos
    • 2.1 Véase también
    • 2.2 Referencias

Control de concurrencia en bases de datos

Comentario:

  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, los objetos transaccionales de Sistemas de gestión y en redes de smartphones que generalmente implementan sistemas de base de datos privada y dedicado), no sólo para fines generales sistemas de gestión de base de datos (DBMS).
  2. DBMS debe tratar también con control de concurrencia temas típicos no sólo para las transacciones de la base de datos sino para sistemas operativos en general. Estos temas (por ejemplo, véase Control de concurrencia en los sistemas operativos a continuación) están fuera del alcance de esta sección.

Control de concurrencia en Sistemas de gestión de base de datos (DBMS; por ejemplo, Bernstein et al. 1987, Weikum y Vossen 2001), otros transaccional objetos y relacionadas (por ejemplo, las aplicaciones distribuidas La informatización en red y Computación en la nube) asegura que transacciones de bases de datos se llevan a cabo al mismo tiempo sin violar la integridad de datos del respectivo bases de datos. Así el control de concurrencia es un elemento esencial para la corrección en cualquier sistema donde las transacciones de la base de datos dos o más, ejecutados con superposición de tiempo, puede acceder a los mismos datos, por ejemplo, prácticamente en cualquier sistema de base de datos. En consecuencia se ha acumulado un vasto cuerpo de investigación relacionados ya que los sistemas de bases de datos surgieron en la década de 1970. Un control de concurrencia establecidos teoría para los sistemas de base de datos se perfila en las referencias mencionadas anteriormente: teoría serializabilidad, que permite diseñar eficazmente y analizar mecanismos y métodos de control de concurrencia. Una teoría alternativa para control de concurrencia de transacciones atómicas sobre tipos de datos abstractos se presenta en)Lynch et al., 1993) y no se utiliza por debajo. Esta teoría es más refinado, complejo, con un alcance más amplio y ha sido menos utilizada en la literatura de base de datos que la teoría clásica anterior. Cada teoría tiene sus pros y contras, énfasis y Insight. En cierta medida son complementarias, y su combinación puede ser útil.

Para garantizar la corrección, un DBMS generalmente garantiza que sólo serializable transacción horarios se generan, a menos que serializabilidad es intencionalmente relajado para aumentar el rendimiento, pero sólo en casos donde la corrección de aplicación no es dañada. Para mantener la corrección en los casos de las transacciones (abortados) no (que siempre pueden suceder por muchas razones) horarios también necesitan tener la capacidad de recuperación (de interrupción) propiedad. Un DBMS también no garantiza que ningún efecto de la comprometido las transacciones se pierde y ningún efecto de la abortado (deshace) transacciones permanece en la base de datos relacionado. General caracterización transacción generalmente es resumida por el ÁCIDO reglas siguientes. Como bases de datos se han convertido en distribuido, o necesitan cooperar en entornos distribuidos (por ejemplo, Bases de datos federadas a principios de los 1990, y Computación en la nube en la actualidad), la distribución efectiva de los mecanismos de control de concurrencia ha recibido especial atención.

Transacciones de bases de datos y las reglas ACID

Artículos principales: Transacciones de bases de datos y ÁCIDO

El concepto de un transacciones de bases de datos (o transacción atómica) ha evolucionado para permitir a ambos un comportamiento del sistema de base de datos bien entendida en medio defectuoso donde accidentes pueden ocurrir en cualquier momento, y recuperación de un accidente a un estado de base de datos bien entendida. Una transacción de base de datos es una unidad de trabajo, encapsulando típicamente un número de operaciones sobre una base de datos (por ejemplo, leyendo un objeto de base de datos, escritura, adquiriendo la cerradura, etc.), una abstracción apoyada en bases de datos y también otros sistemas. Cada transacción ha definido límites en cuanto a qué código de programa/ejecuciones están incluidas en la transacción (determinada por el programador de la transacción a través de los comandos especiales de la transacción). Cada transacción de base de datos obedece a las siguientes reglas (por el apoyo en el sistema de base de datos; es decir, un sistema de base de datos está diseñado para garantizarlos para las transacciones funciona):

  • Atomicidad -Los efectos de todos o ninguno de sus operaciones siguen siendo (semántica "todo o nada") cuando un transacción está completado (comprometido o abortado respectivamente). En otras palabras, al mundo exterior una transacción comprometida aparece (por sus efectos sobre la base de datos) ser indivisibles (atómicas), y una transacción abortada no afecta la base de datos, como si nunca hubiera pasado.
  • Consistencia -Cada transacción debe dejar la base de datos en un estado coherente (correcto), es decir, mantener las reglas de integridad predeterminado de la base de datos (restricciones sobre y entre los objetos de la base de datos). Una transacción debe transformar una base de datos de un estado consistente a otro estado consistente (sin embargo, es responsabilidad del programador de la transacción para asegurarse de que la transacción se es correcta, es decir, realiza correctamente lo que se propone realizar (desde el punto de vista de la aplicación) mientras se aplican las reglas de integridad predefinidos por el DBMS). Así como una base de datos puede modificarse normalmente sólo por transacciones, Estados de toda la base de datos son constantes.
  • Aislamiento -Transacciones no interfieran entre sí (como un resultado final de sus ejecuciones). Además, generalmente (dependiendo del método de control de concurrencia) los efectos de una transacción incompleta no son aún visibles para otra transacción. Proporcionar aislamiento es el objetivo principal del control de concurrencia.
  • Durabilidad -Efectos de las transacciones (comprometidos) exitosas deben persistir a través de se bloquea (típicamente mediante el registro de los efectos de la transacción y su evento se comprometen en un memoria no volátil).

El concepto de transacción atómica se ha extendido durante los años que lo ha convertido en Transacciones comerciales que en realidad implementar tipos de Flujo de trabajo y son no atómica. Sin embargo también tales transacciones mejoradas suelen utilizan transacciones atómicas como componentes.

¿Por qué es necesario el control de concurrencia.

Si las transacciones se ejecutan en serie, es decir, secuencialmente con no se solapan en el tiempo, no hay concurrencia de transacción existe. Sin embargo, si se permiten transacciones simultáneas con procesamiento simultáneo de las operaciones en forma descontrolada, puede producirse un resultado inesperado, indeseable, tales como:

  1. El problema de actualización perdida: una segunda transacción escribe un segundo valor de un elemento de datos (referencia) en la parte superior un primer valor escrito por una primera transacción concurrente, y el primer valor se ha perdido para otras transacciones cronológico que necesita, por su prioridad, para leer el primer valor. Las transacciones que han leído el extremo valor incorrecto con resultados incorrectos.
  2. El sucio Lee problema: transacciones leer un valor escrito por una transacción que ha sido abortada más tarde. Este valor desaparece de la base de datos a abortar y no debería haber leído por cualquier transacción ("leer sucio"). Las operaciones de lectura terminan con resultados incorrectos.
  3. El problema incorrecto Resumen: mientras una transacción lleva un resumen sobre los valores de todas las instancias de un elemento de datos repetido, una segunda transacción actualiza algunas instancias de ese elemento de datos. El extracto resultante no refleja un resultado correcto para cualquier (generalmente necesario para corrección) orden de precedencia entre las dos operaciones (si uno se ejecuta antes que el otro), sino más bien un resultado aleatorio, según el momento de las actualizaciones, y si ciertos resultados de actualización se han incluido en el resumen o no.

Mayoría de sistemas transaccional de alto rendimiento necesita ejecutar transacciones simultáneamente para satisfacer sus requerimientos de performance. Por lo tanto, sin control de concurrencia tales sistemas pueden proporcionar resultados correctos ni mantener sus bases de datos consistente.

Mecanismos de control de concurrencia

Categorías

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

  • Optimista -Retrasar la comprobación de si una transacción cumple el aislamiento y las demás normas de integridad (por ej., serializabilidad y capacidad de recuperación) hasta el final, sin bloqueo de alguno de su (leer, escribir) operaciones (".. .y ser optimista acerca de las reglas que nos conocimos...") y luego cancelar una transacción para evitar la violación, si las reglas deseadas están violando a su confirmación. Una transacción abortada es inmediatamente reiniciar y volver a ejecutarlo, que incurre en una evidente sobrecarga (en comparación con ejecutarlo al final sólo una vez). Si no también muchas transacciones son abortadas, entonces ser optimista es generalmente una buena estrategia.
  • Pesimista -Bloquear una operación de una transacción, si puede ocasionar la violación de las reglas, hasta que desaparezca la posibilidad de violación. Bloqueo de operaciones típicamente está implicado con reducción del rendimiento.
  • Semi optimista -Bloquear operaciones en algunas situaciones, si puede provocar violación de algunas reglas y no bloquee en otras situaciones mientras retrasando reglas de comprobación (si es necesario) al final de la transacción, como hizo con optimismo.

Diferentes categorías proporcionan un rendimiento diferente, es decir, la transacción promedio diferente terminación tarifas (rendimiento de procesamiento), dependiendo de transacción se mezclan tipos, Computación nivel de paralelismo y otros factores. Si la selección y conocimiento sobre las compensaciones están disponibles, entonces categoría y método deberán elegirse para proporcionar el rendimiento más alto.

El bloqueo mutuo entre dos transacciones (donde cada uno bloquea al otro) o más resultados en un interbloqueo, donde las transacciones involucradas están bloqueadas y no pueden llegar a completar. Mayoría de los mecanismos no optimista (con bloqueo) es propensa a los interbloqueos que son resueltos por una interrupción intencional de una transacción estancada (que libera las otras transacciones en ese callejón sin salida), y su reinicio inmediato y la ejecución. La probabilidad de un callejón sin salida es típicamente baja.

Bloqueos, bloqueos y todos resultan en la reducción de rendimiento, las interrupciones 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 puede implementarse dentro de cualquier categoría principal anterior. Los métodos principales,[1] que tiene cada muchas variantes y en algunos casos pueden superponerse o combinarse, son:

  1. Bloqueo (por ejemplo, Bloqueo de dos fases -2PL)-control de acceso a datos por cerraduras asignado a los datos. Acceso de la transacción para un elemento de datos (base de datos objeto) bloqueado por otra transacción puede estar bloqueada (dependiendo del tipo de bloqueo y tipo de operación de acceso) hasta el lanzamiento de la cerradura.
  2. Serialización comprobación de gráfico (también llamado serializabilidad, o conflicto o precedencia gráfico comprobación) - buscando ciclos en del horario gráfico y rompiéndolas por interrupciones.
  3. Timestamp pedidos (A) - asignar timestamps de transacciones y controlar o comprobación de acceso a datos por orden de fecha y hora.
  4. Compromiso ordenando (o cometer ordenar; CO) - controlar o comprobar el orden cronológico de las transacciones de eventos se comprometen para que sea compatible con sus respectivas orden de precedencia.

Otros tipos de control de concurrencia principales que se utilizan en combinación con los métodos anteriores incluyen:

  • Control de concurrencia multiversión (MVCC) - aumento de concurrencia y el rendimiento mediante la generación de una nueva versión de un objeto de base de datos cada vez que el objeto está escrito, y que permite las transacciones Lee las operaciones de varias versiones pasadas pertinentes (de cada objeto) dependiendo del método de programación.
  • Índice de control de concurrencia -Sincronización de las operaciones de acceso a índices, en lugar de a los datos de usuario. Métodos especializados ofrecen rendimiento sustanciales ganancias.
  • Modelo de espacio de trabajo privado (Actualización diferida)-Cada transacción mantiene un espacio de trabajo privado para sus datos de acceso, y sus datos cambiados (por ejemplo, se hacen visibles fuera de la transacción sobre su confirmación Weikum y Vossen 2001). Este modelo proporciona un comportamiento de control de concurrencia diferentes con beneficios en muchos casos.

El tipo de mecanismo más común en los sistemas de base de datos desde sus inicios en la década de 1970 ha Fuerte estricto bloqueo de dos fases (SS2PL; también llamada Programación rigurosa o Riguroso 2PL) que es un caso especial (variante) de ambos Bloqueo de dos fases (2PL) y Compromiso ordenando (CO). Es pesimista. A pesar de su largo nombre (por razones históricas) la idea de la SS2PL mecanismo es simple: "Liberar todas las cerraduras aplicadas por una transacción sólo después de que la operación ha terminado". SS2PL (o rigor) es también el nombre del conjunto de todos los horarios que pueden ser generados por este mecanismo, es decir, estos son SS2PL (o rigurosas) horarios, tienen la propiedad SS2PL (o rigor).

Objetivos principales de los mecanismos de control de concurrencia

Control de concurrencia en primer lugar los mecanismos deben funcionar correctamente, es decir mantener la integridad de cada transacción reglas (en relación con la concurrencia; regla de integridad de aplicaciones específicas están fuera del alcance aquí) mientras las transacciones ejecutan concurrentemente y por lo tanto la integridad de todo el sistema transaccional. Corrección debe conseguirse con como buen funcionamiento como sea posible. Además, cada vez más una necesidad existe para operar con eficacia, mientras que las transacciones son distribuido sobre procesos de, ordenadores, y redes de computadores. Otros temas que pueden afectar el control de concurrencia son recuperación y replicación.

Corrección

Serializabilidad
Artículo principal: Serializabilidad

Para la corrección, está generando una meta importante común de la mayoría de los mecanismos de control de concurrencia horarios con el Serializabilidad propiedad. Sin serializabilidad pueden ocurrir fenómenos indeseables, por ejemplo, dinero puede desaparecer de cuentas, o generarse de la nada. Serializabilidad de un programa significa equivalencia (en los valores resultantes de la base de datos) para algunos serial horario con las mismas operaciones (es decir, en la cuales las transacciones son secuenciales con no se solapan en el tiempo y por lo tanto completamente aislados unos de otros: No acceso simultáneo de las dos transacciones a los mismos datos es posible). Serializabilidad es considerado el más alto nivel de aislamiento entre transacciones de bases de datosy el criterio de corrección importante de transacciones simultáneas. En algunos casos comprometieron, formas relajadas de serializabilidad son permitidos para un mejor rendimiento (por ejemplo, el popular Aislamiento de instantánea mecanismo) o para cumplir con disponibilidad de requisitos en sistemas altamente distribuidos (véase Consistencia eventual), pero sólo si la corrección de la aplicación no es violada por la relajación (por ejemplo, no hay relajación está permitido para dinero transacciones, ya que por la relajación dinero puede desaparecer o aparecer de la nada).

Casi todos los mecanismos de control de concurrencia implementados lograr la serializabilidad Serializablity conflictos, un caso especial amplio de serializabilidad (es decir, cubre, permite a los horarios más serializables y no impone importantes restricciones adicionales que causan retraso) que se puede implementar eficientemente.

Capacidad de recuperación
Ver Capacidad de recuperación en Serializabilidad

Comentario: Mientras que en el área general de los sistemas que el término "recuperación" puede referirse a la capacidad de un sistema para recuperar de fracaso o de un estado incorrecto/prohibido, en concurrencia control de sistemas de base de datos este término ha recibido un significado específico.

Control de concurrencia típicamente también asegura la Capacidad de recuperación propiedad de horarios para mantener la corrección en los casos de transacciones abortadas (que siempre pueden suceder por muchas razones). Capacidad de recuperación (de interrupción) significa que ninguna transacción comprometido en un horario ha leer datos escritos por una transacción abortada. Tales datos desaparecen de la base de datos (sobre la interrupción) y forman parte de un estado de base de datos incorrectos. Leyendo los datos viola la regla de la consistencia de ácido. A diferencia de serializabilidad, capacidad de recuperación no puede ser comprometida, relajado en cualquier caso, desde ningún resultado de relajación en violación de integridad de base de datos rápida sobre las interrupciones. Los principales métodos mencionados proporcionan mecanismos serializabilidad. Ninguno de ellos en su forma general proporciona automáticamente la capacidad de recuperación, y consideraciones especiales y mecanismo mejoras son necesarias para apoyar la capacidad de recuperación. Es un caso especial comúnmente utilizado de recuperación Rigor, que permite la recuperación de base de datos eficiente de fracaso (pero excluye las implementaciones optimistas; por ejemplo, CO estricta (SCO) No se puede tener una aplicación optimista, pero tiene unos semi optimistas).

Comentario: Tenga en cuenta que el Capacidad de recuperación propiedad es necesaria incluso si ninguna falla y ninguna base de datos recuperación de fracaso es necesario. Más bien es necesario controlar correctamente automáticamente las interrupciones de la transacción, que pueden estar relacionadas a la falta de base de datos y recuperación de ella.

Distribución

Con el desarrollo tecnológico rápido de la diferencia entre locales y distribuidos de Computación Informática sobre baja latencia redes o autobuses es borrosa. Por lo tanto es común, por ejemplo, en la utilización efectiva de técnicas locales en dichos entornos distribuidos clusters de computadoras y procesadores multi-core. Sin embargo las técnicas locales tienen sus limitaciones y utilizan múltiples procesos (o hilos) apoyado por múltiples procesadores (o núcleos múltiples) a escala. Esto convierte a menudo las transacciones en los distribuidos, si se necesitan para abarcar múltiples procesos. En estos casos la mayoría de las técnicas de control de concurrencia local no escala bien.

Serializabilidad distribuido y compromiso ordenando
Ver Serializabilidad distribuido en Serializabilidad
Artículo principal: Serializabilidad global
Artículo principal: Compromiso ordenando

Como sistemas de base de datos se han convertido en distribuido, o comenzó a cooperar (por ejemplo, en entornos distribuidos Bases de datos federadas en la década de 1990 y en la actualidad La informatización en red, Computación en la nubey redes con smartphones), algunas transacciones se han distribuido. A transacciones distribuidas significa que la transacción se extiende procesos dey pueden abarcar ordenadores y sitios geográficos. Esto genera una necesidad de efectivo control de concurrencia distribuido mecanismos. Lograr la propiedad serializabilidad de programación de un sistema distribuido (véase Serializabilidad distribuido y Serializabilidad global (Serializabilidad modular)) efectivamente plantea desafíos especiales típicamente no conocidos por la mayoría de los mecanismos regulares serializabilidad, originalmente diseñados para operar localmente. Esto es especialmente debido a la necesidad de costosos distribución de información de control de concurrencia en el medio de comunicación e informática latencia. La única técnica efectiva general conocida de distribución es compromiso de ordenar, que fue divulgada públicamente en 1991 (después de haber sido patentado). Compromiso ordenando (Cometer ordenar, CO; Raz 1992) significa que el orden cronológico de las transacciones de eventos cometer se mantenga compatible con sus respectivas orden de precedencia. CO no requiere la distribución de información de control de concurrencia y proporciona una solución eficaz general (confiable, alto rendimiento, y escalable) para serializabilidad tanto distribuida y global, también en un entorno heterogéneo con sistemas de base de datos (u otros objetos transaccionales) con diferentes (cualquier tipo) concurrencia control de mecanismos.[1] CO es indiferente a qué mecanismo se utiliza, puesto que no interfiere con cualquier operación de transacción programación (que más control de mecanismos) y sólo determina el orden de los acontecimientos de cometer. Por lo tanto, CO permite la distribución eficiente de todos los otros mecanismos y también la distribución de una mezcla de diferentes (cualquier tipo) los mecanismos locales, para lograr serializabilidad distribuida y global. La existencia de esta solución ha sido considerada "poco probable" hasta 1991 y por muchos expertos también más adelante, debido a la incomprensión de la Solución de CO (véase Citas en Serializabilidad global). Es un importante beneficio de lado de CO resolución automática de deadlocks distribuidos. Contrariamente a CO, son propensas a prácticamente todas las técnicas (al no combinarse con CO) deadlocks distribuidos (también llamado globales interbloqueos) que necesitan un tratamiento especial. CO es también el nombre de la propiedad resultante del programa: un horario tiene la propiedad de CO si el orden cronológico de los acontecimientos de sus transacciones se comprometen es compatible con las respectivas transacciones orden de precedencia (parcial).

SS2PL mencionado anteriormente es una variante (caso especial) de CO y así también eficaz para lograr serializabilidad distribuida y global. También proporciona resolución automática de deadlocks distribuidos (hecho por alto en la literatura de investigación incluso después de la publicación del CO), así como el rigor y por lo tanto la capacidad de recuperación. Poseer estos deseado propiedades junto a conocidos eficientes bloqueo basado en implementaciones explica la popularidad de SS2PL. SS2PL se ha utilizado para lograr eficientemente distribuidos y serializabilidad Global desde el 1980 y se ha convertido en el estándar de facto para ello. Sin embargo, SS2PL bloqueo y restricción (pesimista) y con la proliferación de distribución y utilización de sistemas diferentes de sistemas de bases de datos tradicionales (por ejemplo, como en Computación en la nube), menos vinculantes (por ejemplo, tipos de CO Optimista CO) puede ser necesaria para un mejor rendimiento.

Comentario:

  1. El Serializabilidad conflicto distribuidos propiedad en su forma general es difícil de lograr en forma eficiente, pero eficiente se logra mediante su caso especial CO distribuido:: Cada componente local (por ejemplo, un DBMS local) necesita tanto para proporcionar algún tipo de CO y hacer cumplir un especial voto pedido estrategia para el Protocolo de dos fases (2PC: utilizados para cometer transacciones distribuidas). Diferentemente del general distribuido CO, SS2PL distribuida existe automáticamente cuando todos los componentes locales son SS2PL base (en cada componente CO existe, IMPLÍCITA, y el voto pedido estrategia ahora se cumple automáticamente). Este hecho ha sido conocida y utilizada desde la década de 1980 (es decir, que SS2PL existe a nivel mundial, sin que sepa CO) para SS2PL de distribución eficiente, lo que implica serializabilidad distribuido y rigor (por ejemplo, véase Raz 1992, página 293; también se implica en Bernstein et al. 1987Página 78). Menos restringidas serializabilidad distribuido y rigor puede lograrse eficientemente por distribuido CO estricta (SCO), o por una mezcla de SS2PL base y SCO basado en componentes locales.
  2. Acerca de las referencias y compromiso pedidos: ()Bernstein et al. 1987) fue publicado antes del descubrimiento del CO en 1990. Se llama a la propiedad de horario CO Atomicidad dinámico en)Lynch et al., 1993Página 201). CO se describe en)Weikum y Vossen 2001páginas 102, 700), pero la descripción es parcial y se pierde Esencia de CO. (Raz 1992) fue la primera arbitrado y aceptado para su publicación Encyclopedia CO algoritmos (sin embargo, publicaciones sobre una propiedad equivalente dinámico atomicidad se remonta a 1988). Otros Artículos de CO seguido. (Bernstein y recién llegado de 2009)[1] Nota CO como uno de los cuatro métodos de control de mayor concurrencia y capacidad de CO para proporcionar interoperabilidad entre otros métodos.
Recuperación distribuida

A diferencia de serializabilidad, Recuperación distribuida y Rigor distribuido puede lograrse eficazmente de forma sencilla, similar a la forma CO distribuido se consigue: en cada sistema de base de datos tienen que ser aplicadas localmente y emplear un voto pedido estrategia para el Protocolo de dos fases (2PC; Raz 1992Página 307).

Como se ha mencionado anteriormente, distribuido SS2PL, incluyendo el rigor distribuido (recuperación) y distribuido compromiso ordenando (serializabilidad), emplea el voto necesario ordenar estrategia automáticamente y cuando se logra (globalmente) empleado localmente en cada sistema de base de datos (local) (como ha sido conocida y utilizada por muchos años; como un asunto de la localidad de hecho está definido por el límite de una (participante) 2PCRaz 1992) ).

Otros temas importantes de la atención

El diseño de mecanismos de control de concurrencia a menudo está influenciado por los siguientes temas:

Recuperación
Artículo principal: Recuperación de datos

Todos los sistemas son propensos a fallas y manejo recuperación de fracaso es una necesidad. Las propiedades de los horarios generados, que son dictados por el mecanismo de control de concurrencia, pueden tener un impacto en la eficacia y eficiencia de recuperación. Por ejemplo, la propiedad de rigor (mencionada en la sección Capacidad de recuperación arriba) a menudo es deseable para una recuperación eficiente.

Replicación
Artículo principal: Replicación (informática)

Para una alta disponibilidad a menudo son objetos de base de datos replicado. Actualizaciones de réplicas de un mismo objeto de base de datos deben mantenerse sincronizada. Esto puede afectar la forma de hace control de concurrencia (por ejemplo, Gray et al 1996[2]).

Véase también

  • Horario
  • Aislamiento (informática)
  • Control de concurrencia distribuido
  • Control de concurrencia global

Referencias

  • Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (1987): Control de concurrencia y recuperación en sistemas de base de datos (descarga gratuita de PDF), Addison Wesley Publishing Company, 1987, ISBN 0-201-10715-5
  • Gerhard Weikum, Gottfried Vossen (2001): Sistemas de información transaccional, Elsevier, ISBN 1-55860-508-8
  • Nancy Lynch, Michael Merritt, William Weihl, Alan Fekete (1993): Transacciones atómicas en sistemas distribuidos y concurrentes , Morgan Kauffman (Elsevier), agosto de 1993, ISBN 978-1-55860-104-8, ISBN 1-55860-104-X
  • Yoav Raz (1992): "El principio de compromiso ordenando, o garantizar serializabilidad en un entorno heterogéneo de múltiples administradores de recursos autónomos mediante compromiso atómico". (PDF), Actas de la XVIII Conferencia Internacional sobre Bases de datos muy grandes (VLDB), págs. 292-312, Vancouver, Canadá, agosto de 1992. (también 841 DEC-TR, Digital Equipment CorporationDe noviembre de 1990)

Notas al pie

  1. ^ a b c Philip A. Bernstein, Eric Newcomer (2009): Principios de procesamiento de transacciones, 2ª edición, Morgan Kaufmann (Elsevier), junio de 2009 ISBN 978-1-55860-623-4 (página 145)
  2. ^ Gray, J.; Helland, P.; O ' Neil, p.; Shasha, D. (1996). "Los peligros de replicación y una solución". "Procedimientos del 1996 ACM SIGMOD Conferencia Internacional sobre gestión de datos". págs. 173-182. Doi:10.1145/233269.233330.

Control de concurrencia en los sistemas operativos

Multitarea sistemas operativos, especialmente sistemas operativos en tiempo real, es necesario mantener la ilusión de que todas las tareas corriendo encima de ellos son todos corriendo al mismo tiempo, aunque sólo una o unas pocas tareas realmente apuntan en cualquier momento debido a las limitaciones del hardware del sistema operativo se está ejecutando en. Tan multitarea es bastante simple, cuando todas las tareas son independientes uno del otro. Sin embargo, cuando varias tareas intentan utilizar el mismo recurso, o cuando las tareas trata de compartir información, puede llevar a confusión e inconsistencia. La tarea de Computación concurrente es para resolver el problema. Algunas soluciones implican "cerraduras" similares a las cerraduras utilizadas en bases de datos, pero corren el riesgo de causar sus propios problemas tales como interbloqueo. Otras soluciones son Algoritmos sin bloqueo y Read-copy-update.

Véase también

  • Linearizability
  • Exclusión mutua
  • Semáforo (programación)
  • Cerradura (informática)
  • Software de memoria transaccional
  • Extensiones de sincronización transaccional

Referencias

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

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Concurrency_control&oldid=632557272"