ES2320601T3 - Metodo para reconstruir el estado de un calculo. - Google Patents
Metodo para reconstruir el estado de un calculo. Download PDFInfo
- Publication number
- ES2320601T3 ES2320601T3 ES96943730T ES96943730T ES2320601T3 ES 2320601 T3 ES2320601 T3 ES 2320601T3 ES 96943730 T ES96943730 T ES 96943730T ES 96943730 T ES96943730 T ES 96943730T ES 2320601 T3 ES2320601 T3 ES 2320601T3
- Authority
- ES
- Spain
- Prior art keywords
- execution
- phase
- application
- program
- orders
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1474—Saving, restoring, recovering or retrying in transactions
Abstract
PROCEDIMIENTOS Y SISTEMAS PARA EJECUTAR Y VERIFICAR APLICACIONES EN PARALELO Y DISTRIBUIDAS QUE NO PRECISAN MODIFICAR LOS PROGRAMAS UTILIZADOS EN EL SISTEMA NI EFECTUAR MODIFICACIONES EN EL SISTEMA OPERATIVO UTILIZADO. UNA REALIZACION DE LA INVENCION INCLUYE LAS SIGUIENTES OPERACIONES GENERALES: INICIAR UNA APLICACION EN UN SISTEMA DE PROCESAMIENTO PARALELO (40), CONTROLAR LOS PROCESOS PARA LA APLICACION, QUE INCLUYE REGISTRAR COMANDOS Y RESPUESTAS (41, 42, 43), CONTROLAR UN PROTOCOLO UTILIZADO (44), DETECTAR FALLOS DE LAS APLICACIONES (45, 46) Y CONTINUAR LA EJECUCION DE LA APLICACION A PARTIR DE LA OPERACION MAS RECIENTEMENTE REALIZADA DESPUES DE "REPRODUCIR" LOS COMANDOS Y RESPUESTAS REGISTRADOS (47).
Description
Método para reconstruir el estado de un
cálculo.
Este invento se refiere a sistemas de
tratamiento por ordenador y, más particularmente, a métodos y
sistemas para reconstruir el estado de un cálculo interrumpido en
un entorno de ordenador con tratamiento en paralelo.
Las velocidades de cálculo de los ordenadores
monoprocesador han avanzado en forma muy considerable en las
últimas tres décadas. Sin embargo, muchos campos requieren una
capacidad de cálculo que supera, incluso, la del ordenador
monoprocesador más rápido. Un ejemplo reside en un tratamiento
transaccional, en que múltiples usuarios acceden en forma
concurrente a los recursos del ordenador y en el que los tiempos de
respuesta deben ser bajos para que el sistema sea comercialmente
aceptable. Otro ejemplo reside en la minería de bases de datos, en
donde deben tratarse centenares de gigabytes de información, y donde
el tratamiento de datos en un ordenador en serie podría llevar días
o semanas. En consecuencia, se ha desarrollado una variedad de
sistemas de "tratamiento en paralelo" para resolver tales
problemas. Para los fines de esta exposición, los sistemas de
tratamiento en paralelo incluyen cualquier configuración de sistemas
de ordenador que utilicen múltiples unidades centrales de
tratamiento (CPU), ya sean locales (por ejemplo, sistemas
multiprocesador tales como los ordenadores SMP), ya sean localmente
distribuidos (por ejemplo, múltiples procesadores acoplados como
conglomerados o MPP), o remotos o remotamente distribuidos (por
ejemplo, múltiples procesadores acoplados a través de redes LAN o
WAN) o cualquier combinación de ellos.
Típicamente, las aplicaciones complejas de
tratamiento de datos que se ejecutan en sistemas de tratamiento en
paralelo llevan a cabo cambios en múltiples colecciones externas de
datos (ficheros, bases de datos, etc.). Tales aplicaciones hacen
esto ejecutando uno o más programas de forma concurrente o en
secuencia. Si se produce un fallo, pueden haberse introducido
cambios en las colecciones externas de datos que hagan que estos no
puedan ser utilizados por la aplicación en curso o por otras
aplicaciones. En los sistemas de tratamiento en paralelo, el
problema se agrava ya que la colección de datos se extenderá, con
frecuencia, por muchos nodos y unidades de almacenamiento (por
ejemplo, discos magnéticos) diferentes, haciendo que el trabajo
requerido para "volver atrás" el estado de los datos se
incremente proporcionalmente con el número de unidades de
almacenamiento. De manera similar, el número de programas que deben
terminarse puede ser elevado.
Para recuperarse de tales fallos, es necesario
interrumpir la aplicación en curso (es decir, la que ha fallado) y,
luego
- (1)
- deshacer todos los cambios realizados por las aplicaciones desde el arranque (una "vuelta atrás total"), o
- (2)
- devolver el estado del sistema a un "punto de control" intermedio y reiniciar la ejecución desde ese punto (una "vuelta atrás parcial").
\vskip1.000000\baselineskip
Las vueltas atrás parciales desde un punto de
control (denominadas también "utilización de puntos de
control") tienen ventajas con respecto a las vueltas atrás
totales, por cuanto se perderá menos trabajo si se produce un
fallo, y las vueltas atrás parciales requieren conservar menos
información. Sin embargo, la utilización de puntos de control
constituye un problema técnico complicado, dado que es difícil (1)
capturar el estado de programas en ejecución; (2) volver hacia
atrás en forma consistente el estado de todos los ficheros de datos
que se modifican; y (3) capturar datos en tránsito entre programas
(por ejemplo, datos que están siendo enviados por una red). El
problema se complica por el hecho de que, en la mayoría de los
casos, los programas de aplicación deben escribirse especialmente
para proporcionar el empleo de puntos de control. En general, no es
posible modificar programas no diseñados para ello con el fin de
añadir llamadas explícitas a un paquete de software de empleo de
puntos de control sin llevar a cabo cambios sustanciales en el
código fuente del programa. Además, la mayoría de los sistemas
operativos no proporcionan medidas para capturar datos en tránsito
entre programas.
El documento US 4665520 describe un método para
la recuperación de una aplicación que ha fallado en un sistema de
tratamiento distribuido utilizando la vuelta atrás mediante puntos
de control, en combinación con registro/reproducción de mensajes
entre procesos.
El documento US 5440726 describe una
recuperación progresiva del proceso en una aplicación de intercambio
de mensajes en un sistema de tratamiento en paralelo utilizando
creación de puntos de control/vuelta atrás del proceso de la
aplicación, junto con registro/reproducción de mensajes.
El documento EP 0578406 describe un método para
la recuperación de un programa de aplicación de transacciones
distribuidas que utiliza un protocolo de confirmación de
transacciones en dos fases mediante el uso de un registro de
recuperación de transacciones, que es reproducido cuando se reinicia
la aplicación.
En consecuencia existe la necesidad de un método
de proporcionar el uso de puntos de control para aplicaciones que
no lo hagan específicamente. El presente invento proporciona un
método de esta clase que sea particularmente útil para aplicaciones
que se ejecutan en sistemas de tratamiento en paralelo y, también,
útil para aplicaciones que se ejecuten en sistemas de tratamiento
distribuido.
El presente invento, que se define con detalle
en las reivindicaciones independientes adjuntas, reside en un
método y un sistema para ejecutar y almacenar el estado de cálculo
en aplicaciones en paralelo y distribuidas, que no exija
modificación alguna de los programas utilizados en el sistema ni
cambios en el sistema operativo subyacente. El invento
comprende dos realizaciones diferentes. La primera realización preferida comprende los siguientes pasos generales:
comprende dos realizaciones diferentes. La primera realización preferida comprende los siguientes pasos generales:
- (1)
- iniciar una aplicación en un sistema de tratamiento en paralelo;
- (2)
- controlar los procesos para la aplicación, incluyendo el registro de órdenes y respuestas;
- (3)
- controlar un protocolo de confirmación;
- (4)
- detectar fallos de la aplicación;
- (5)
- continuar la ejecución de la aplicación desde la transacción más recientemente confirmada después de "reproducir" las órdenes y las respuestas registradas.
\vskip1.000000\baselineskip
La segunda realización preferida comprende los
siguientes pasos generales:
- (1)
- iniciar una aplicación en un sistema de tratamiento en paralelo;
- (2)
- controlar los procesos de la aplicación, incluyendo el registro recurrente de la imagen de la memoria de un programa controlador que controla la aplicación;
- (3)
- controlar un protocolo de confirmación;
- (4)
- detectar fallos de la aplicación;
- (5)
- continuar la ejecución de la aplicación a partir de la transacción más recientemente confirmada después de "restaurar" la imagen de la memoria registrada del programa controlador.
\vskip1.000000\baselineskip
Las características principales de la
arquitectura del invento son:
- (1)
- Control central: Las aplicaciones se ejecutan desde un punto central de control. En la realización preferida, un único programa "controlador" con un único hilo de control ilustra y vigila todos los programas y colecciones de datos que constituyen la aplicación.
- (2)
- Control mediante anfitrión y agentes: Para permitir la distribución del tratamiento entre múltiples nodos, se utiliza un programa denominado "agente" para activar cambios en nodos remotos. En la realización preferida, se forma, en cada nodo, una instancia de un agente separado. El control global del sistema se mantiene mediante un programa "anfitrión", que gestiona las comunicaciones con el programa controlador y los agentes, y mantiene el estado global del sistema.
- (3)
- Un único canal de órdenes: Se mantiene un "canal de órdenes" entre el programa controlador y el programa anfitrión. En la realización preferida, el programa controlador solamente realiza cambios en el sistema mediante un conjunto de órdenes y contestaciones utilizando el canal de órdenes.
- (4)
- Registro del tráfico por el canal de órdenes o imagen de la memoria: En la primera realización, todas las órdenes y contestaciones que pasan por el canal de órdenes son registradas por el programa anfitrión y guardadas en un almacenamiento no volátil. En la segunda realización, la imagen de la memoria del programa controlador que controla la aplicación, es grabada concurrentemente por el programa anfitrión y guardada en un almacenamiento no volátil.
- (5)
- Control basado en las transacciones: En la realización preferida, todas las operaciones realizadas a través del canal de órdenes utilizan un protocolo de confirmación (de preferencia un protocolo de confirmación en dos fases), para garantizar la atomicidad global.
- (6)
- Recuperación con recapitulación: Utilizando los antes mencionados mecanismos, el invento proporciona la posibilidad de "recuperar" una aplicación que haya fallado, simplemente, volviendo a ponerla en ejecución. Dicho en pocas palabras, el estado de todos los datos es restaurado a través del protocolo de confirmación, luego se utiliza el tráfico registrado en el canal de órdenes para "engañar" al programa controlador haciéndole creer que se está ejecutando de nuevo la aplicación, o se restaura la imagen de la memoria del último estado bueno conocido para el programa controlador. Debido a la naturaleza determinística de los programas de ordenador de hilo único, el programa controlador acabará, necesariamente, como último estado bueno conocido, en el mismo estado que lo hizo la primera vez que se ejecutó el programa.
\vskip1.000000\baselineskip
El principal uso proyectado del invento reside
en las aplicaciones tradicionales de tratamiento de datos (por
ejemplo, sistemas contables, sistemas de transacciones en tandas,
etc.), pero el invento podría aplicarse en casi cualquier
aplicación de ordenador que lleve a cabo cambios en ficheros o en
bases de datos.
Los detalles de la realización preferida del
presente invento se establecen en los dibujos adjuntos y en la
descripción que sigue. Una vez se conozcan los detalles del invento,
a un experto en la técnica le resultarán evidentes numerosos
cambios e innovaciones adicionales.
La figura 1 es un diagrama de bloques que
muestra los componentes de software y el flujo de control de un
sistema de creación de puntos de control de acuerdo con el presente
invento.
La figura 2a es un diagrama de bloques que
muestra la ejecución normal de un programa dotado de puntos de
control de acuerdo con el presente invento.
La figura 2b es un diagrama de bloques que
muestra un fallo durante la ejecución del programa con puntos de
control de la figura 2a.
La figura 2c es un diagrama de bloques que
muestra la recuperación del fallo de la figura 2b.
La figura 3 es un diagrama de bloques que
muestra los componentes de software y el flujo de control de un
sistema de creación de puntos de control durante la recuperación de
un fallo de acuerdo con el presente invento.
La figura 4 es una gráfica de control que
muestra en forma resumida las operaciones funcionales básicas de la
realización de recapitulación del presente invento.
La figura 5 es una gráfica de flujo que muestra,
en forma resumida, las operaciones funcionales básicas de la
realización de restauración del presente invento.
Designaciones y números de referencia similares
indican elementos similares en las distintas figuras.
En toda esta descripción, los ejemplos y la
realización preferida ilustrados deben considerarse como
ilustrativos y no como limitaciones del presente invento.
La figura 1 es un diagrama de bloques que
muestra los componentes de software y el flujo de control del
sistema para guardar periódicamente el estado de ejecución del
programa, de acuerdo con el presente invento. Un sistema anfitrión
10 incluye un programa anfitrión 12, un programa controlador 14 y un
sistema 16 de almacenamiento de datos para registrar órdenes y
contestaciones. El programa anfitrión 12 y el programa controlador
14 están acoplados mediante un canal de órdenes 18 (que, por
ejemplo, puede ser un canal lógico de una línea de transmisión
física). En la realización preferida, el programa anfitrión 12 es,
realmente, un objeto contenido en el espacio de direcciones del
programa controlador 14. En su lugar podría incorporarse un proceso
separado que ejecutase el programa anfitrión. Sin embargo, la
división en "programa anfitrión" y "programa controlador"
es una forma conveniente de describir la arquitectura del presente
invento.
El sistema anfitrión 10 está acoplado a, por lo
menos, un sistema remoto 20 por medio de un canal 22 de
comunicaciones de agente (que, por ejemplo, puede ser un canal
lógico en un enlace de datos físico 22 usual). Dentro de cada
sistema remoto 20 hay un agente 24 que está acoplado al
almacenamiento de datos remoto 26.
Todos los componentes ilustrados en la figura 1
están activos durante una ejecución normal. El programa controlador
14 emite órdenes al programa anfitrión 12 para efectuar operaciones
en aplicaciones en varios sistemas remotos 20. El programa
anfitrión 12 responde a tales órdenes emitiendo órdenes para que uno
o más agentes 24 realicen las operaciones requeridas. Los agentes
24 contestan al programa anfitrión 12 cuando se completan las
operaciones, y el programa anfitrión 12 contesta, a su vez, al
programa controlador 14. Todas las órdenes y contestaciones
intercambiadas entre el programa controlador 14 y el programa
anfitrión 12 son registradas en el sistema 16 de almacenamiento de
datos.
La figura 2a ilustra la ejecución normal de un
programa en un sistema dotado de puntos de control, para guardar
periódicamente el estado de ejecución, de acuerdo con el presente
invento. En el ejemplo mostrado, la aplicación se ejecuta en tres
fases, comenzando en un estado inicial 0, continuando en la fase 0
hasta un estado de punto de control 1, siguiendo luego por la fase
2 hasta un estado de punto de control 2 y, luego, por la fase 3
hasta un estado final.
La figura 2b es un diagrama de bloques que
muestra un fallo durante la ejecución del programa con puntos de
control de la figura 2a. Un fallo puede producirse si, por ejemplo,
uno de los nodos "cae" y ha de volverse a poner en marcha de
nuevo. En el ejemplo ilustrado, algo después de haberse alcanzado el
estado del punto de control 1, se produce un fallo. La ejecución se
detiene en mitad de la fase 1, dejando el estado externo de los
sistemas de tratamiento en paralelo en un estado de fallo
indeseable.
La figura 2c es un diagrama de bloques que
muestra la recuperación del fallo ilustrado en la figura 2b gracias
al uso del presente invento. Cuando la aplicación se recupera
volviendo a ejecutarla de nuevo, se vuelven atrás las operaciones
realizadas en la fase 1 que ha fallado, devolviendo el estado
externo del sistema de tratamiento al estado que existía en el
estado del punto de control 1. Luego, se "restauran" o se
"recapitulan" todas las fases terminadas (en este ejemplo, la
fase 0). En la recapitulación, el programa controlador 14 parte de
nuevo de su estado inicial y funciona normalmente. Sin embargo, no
se producen cambios del estado externo hasta que el programa 14
llega al mismo estado que existía en el estado del punto de control
1. En la restauración, se restaura la imagen guardada del programa
controlador 14 y, luego, empieza a funcionar normalmente desde ese
punto. Después de ello, se ejecutan normalmente la fase que ha
fallado (la fase 1 en este ejemplo) y todas las fases
subsiguientes, llevando la aplicación a través del estado del punto
de control 2 y, de allí, al estado final.
La figura 3 es un diagrama de bloques que
muestra la arquitectura de un sistema con puntos de control de
acuerdo con el presente invento, durante una recapitulación.
Durante el modo de recapitulación, el programa controlador 14 parte
del estado inicial. Cada orden procedente el programa controlador 14
es emitida de nuevo al programa anfitrión 12, que compara esa orden
con las órdenes y contestaciones registradas, previamente
almacenadas en el sistema 16 de almacenamiento de datos. En tanto
la secuencia de órdenes procedentes del programa controlador 14
coincidan con las órdenes registradas, las contestaciones
registradas correspondientes pueden ser alimentadas de nuevo por el
programa anfitrión 12 al programa controlador 14, "engañando",
en efecto, al programa controlador 14 que piensa que las fases que
están siendo recapituladas, se están ejecutando, de hecho,
normalmente. Sin embargo, no se está transformando, moviendo, etc.,
dato alguno. Así, el paso de recapitulación se ejecuta de forma
extremadamente rápida, hasta que el programa controlador 14 alcanza
el estado del último punto de control bueno conocido. En ese punto,
el programa controlador 12 sale del modo de recapitulación y retoma
el modo de funcionamiento normal, proporcionando órdenes desde el
programa controlador 14 a los agentes 24 de los sistemas remotos
20, en forma normal.
El invento puede llevarse a la práctica mediante
hardware o mediante software, o mediante una combinación de ambos.
Sin embargo, de preferencia, el invento se pone en práctica en
programas de ordenador que se ejecutan en ordenadores programables
que comprenden, cada uno, un procesador, un sistema de
almacenamiento de datos (que incluye elementos de almacenamiento
y/o de memoria volátil y no volátil), al menos un dispositivo de
entrada y, al menos un dispositivo de salida. Se aplica código de
programa a los datos de entrada para realizar las funciones
descritas en este documento y generar información de salida. La
información de salida se aplica, en forma conocida, a uno o más
dispositivos de salida.
Cada programa se escribe, preferiblemente, en un
lenguaje de programación orientado a objetos o de elevado nivel
procedimental para comunicar con un sistema de ordenador. Sin
embargo, los programas pueden escribirse, si se desea, en lenguaje
de máquina o ensamblador. En cualquier caso, el lenguaje puede ser
un lenguaje compilado o interpretado.
Cada uno de tales programas de ordenador se
almacena, de preferencia, en un medio o dispositivo de
almacenamiento (por ejemplo, una ROM o un disquete magnético) que
pueda ser leído por un ordenador programable para fines generales o
especiales, para configurar y hacer funcionar el ordenador cuando el
medio o dispositivo de almacenamiento sea leído por el ordenador
para llevar a cabo los procedimientos descritos en este documento.
También puede considerarse llevar a la práctica el sistema del
invento como medio de almacenamiento legible por un ordenador,
configurado con un programa de ordenador, cuyo medio de
almacenamiento así configurado haga que un ordenador funcione de
forma específica y predefinida para ejecutar las funciones descritas
en este documento.
\vskip1.000000\baselineskip
El invento hace uso de un programa controlador
14 que proporciona funciones de supervisión para establecer y
controlar la ejecución de uno o más programas existentes sin puntos
de control. Si se desea, pueden incluirse funciones adicionales. En
la realización preferida, el programa controlador 14 realiza, por lo
menos, las funciones definidas en lo que sigue:
- (a)
- Iniciar tarea. Cuando arranca el programa controlador 14, solicita que el sistema anfitrión 10 cree una instancia del programa anfitrión 12. El sistema anfitrión 10 responde proporcionando al programa controlador 14 un identificador o puntero hacia un canal 18 de órdenes para comunicación con el programa anfitrión 12 y el sistema 16 de almacenamiento de datos. El programa controlador 14 se conecta con el programa anfitrión 12 por el canal 18 de órdenes y emite una orden de "iniciar tarea" para el programa anfitrión 12. Esta orden incluye el nombre de un "fichero de recuperación" que ha de ser establecido por el sistema anfitrión 10 en el sistema 16 de almacenamiento de datos. (En algunas ejecuciones prácticas, la "conexión" puede requerir que se inicie un proceso separado; en otras ejecuciones prácticas, la "conexión" únicamente requiere que se inicialicen algunas estructuras de datos internas. En cualquier caso, la primera acción es, siempre, iniciar una tarea como se ha descrito).
- (b)
- Órdenes: El canal de órdenes 18 acepta, al menos, las siguientes órdenes del programa controlador 14:
- (1)
- Llamar a procedimiento remoto: Esta llamada hace que un agente remoto 24 ejecute una orden. La orden de llamar a procedimiento remoto (RPC) especifica el nodo en el que ha de ejecutarse la orden. Si en ese nodo no hay ningún agente que se esté ejecutando en ese momento, el programa anfitrión 12 pone en marcha un agente remoto 24 en dicho nodo.
- (2)
- Iniciar proceso: Esta orden hace que un agente 24 inicie un proceso. De nuevo, la orden especifica el nodo en el que ha de ejecutarse el proceso. Si en ese nodo, en ese momento, no se está ejecutando ningún agente, el programa anfitrión 12 pone en marcha un agente remoto 24 en dicho nodo.
- (3)
- Esperar. Esta orden hace que se suspenda la ejecución de una función del programa controlador 14 hasta que todos los procesos hayan finalizado su ejecución.
- (4)
- Preparar; Confirmar; Volver atrás. Estas tres órdenes tienen su significado usual en la técnica anterior en lo que respecta a un protocolo usual de tratamiento de transacciones con confirmación en dos fases.
- (c)
- Recepción de contestaciones. Cada orden tiene como consecuencia exactamente un mensaje de contestación. Las órdenes y las contestaciones pueden entremezclarse arbitrariamente (por ejemplo, pueden emitirse varias órdenes antes de que retornen las contestaciones correspondientes). El programa controlador 14 acepta, al menos, las siguientes contestaciones del programa anfitrión 12:
- (1)
- Contestación a la llamada a procedimiento remoto: El contenido de este mensaje es específico para el procedimiento que se invocó mediante una orden de RPC.
- (2)
- ID de proceso: Cuando se inicia un proceso en un sistema (anfitrión 10 o remoto 20), el sistema contesta con un identificador para ese proceso.
- (3)
- Estado de espera: Una indicación sobre si los diversos procesos terminaron con éxito.
- (4)
- Estado de Preparar/Confirmar/Volver atrás. Un indicador de un suceso o un estado de fallo.
- (d)
- Abortar: Esta orden significa que ha de detenerse la ejecución. El programa anfitrión 12 intentará llevar a cabo una vuelta atrás (que puede fallar si, por ejemplo, uno de los nodos involucrados en el cálculo, ha "caído"). Ya tenga éxito o no la vuelta atrás, el canal de órdenes 18 es, típicamente, destruido. Una orden de abortar puede emitirse manualmente mediante el programa controlador 14 si, por ejemplo, el programa controlador 14 detecta un fallo en tiempo de ejecución. También puede emitirse implícitamente una orden de abortar si falla el programa controlador 14.
- (e)
- Terminar tarea. Esta orden significa que no ha de realizarse más trabajo, Típicamente, se destruye el canal de órdenes 18 y todos los cambios realizados por la aplicación se convierten en irrevocables.
- (f)
- Órdenes adicionales. Pueden añadirse, según se desee, órdenes adicionales, pero carecen de importancia para los fines de esta exposición.
\vskip1.000000\baselineskip
Es importante que el programa controlador 14
divide la ejecución de una aplicación en una serie de "fases",
de tal forma que, entre fases, es necesario que todos los procesos
estén inactivos (por ejemplo, terminen o lleguen a un estado de
espera sin que haya transferencias de datos pendientes). Una fase
consiste en los siguientes pasos:
- (1)
- El programa controlador 14 emite una serie de RPC (por ejemplo, para establecer ficheros de datos, etc.) que serán necesarios para uno o más programas de aplicaciones.
- (2)
- Opcionalmente, el programa controlador 14 emite una serie de órdenes de inicio de proceso.
- (3)
- Si se ha iniciado cualquier proceso, entonces, tras haberse puesto en marcha un número deseado de los mismos, el programa controlador 14 emite una orden de esperar y suspende el funcionamiento hasta que termina la espera, dando tiempo, así, a que se completen los procesos. En general, todos los procesos que tengan que llevar a cabo una comunicación cruzada con otros procesos, deben finalizarse de manera concurrente.
- (4)
- Si se desea, la secuencia de pasos (1)-(3) puede repetirse varias veces.
- (5)
- El programa controlador 14 emite órdenes de preparar y confirmar, haciendo que la transacción en curso sea confirmada y que cualesquiera cambios realizados durante la transacción en curso, resulten permanentes.
- (6)
- Siguen otras fases de ejecución.
\vskip1.000000\baselineskip
Un paso clave consiste en emitir la orden de
esperar sobre una base recurrente, ya que una vez terminada esta
orden, se garantiza que en el sistema no existen programas de
aplicación activos y que no hay datos en tránsito en los canales de
comunicaciones. Esta característica permite que el invento soslaye
las dificultades inherentes a la captura de estado de programas en
ejecución y a la captura de datos en tránsito en los canales de
comunicaciones.
Una consecuencia de este diseño es que pueden no
crearse puntos de control mientras los programas están en
ejecución. Si uno de los programas se ejecuta durante varias horas,
entonces habrá, necesariamente, un período de varias horas en el
que no será posible crear un punto de control. Es responsabilidad
del programa de control 14, que con frecuencia habrá sido escrito
por un usuario de este sistema, garantizar que el tiempo de
ejecución de cualquier fase no es excesivo.
En la técnica anterior se cuenta con dos
técnicas que pueden utilizarse para reducir la duración de las
fases. La primera de ellas consiste en reducir el uso de
"encauzamiento" entre etapas sucesivas de un tratamiento
dentro de una fase. Específicamente, una práctica común es
constituir aplicaciones a partir de programas componentes
enlazándolos a través de canales de comunicaciones, técnica
denominada "encauzamiento". Ambos programas componentes se
ejecutarían, necesariamente, en la misma fase. Si a consecuencia de
esto se tuviese una fase demasiado larga, entonces el que escriba
el controlador podría sustituir los canales de comunicaciones por
ficheros temporales y ejecutar cada programa componente en una fase
de ejecución separada. La segunda técnica consiste en dividir los
datos más finamente. Por ejemplo, en vez de tratar un único fichero
con 10 gigabytes, podría dividírsele en 10 subficheros de 1
gigabyte cada uno y tratar cada subfichero en una sola fase de
ejecución. Debido al hecho de que los tiempos de ejecución de la
mayor parte de las aplicaciones son aproximadamente proporcionales
a las longitudes de sus ficheros de entrada, este método podría
conseguir, por ejemplo, una reducción de 10 veces en la duración de
las fases, mejorando notablemente la frecuencia con que pueden
crearse puntos de control. (En la técnica anterior, esta
subdivisión adicional se ha realizado sobre una base
ad-hoc y ha exigido, generalmente, la modificación
de los programas y, quizás, que haya de escribirse software
adicional. Se hace referencia a la solicitud de patente, también en
tramitación, titulada "Sistema de sobredivisión y método de
incrementar los puntos de control en aplicaciones en paralelo
basadas en componentes", cedida al cesionario del presente
invento, en la que se explican algunos métodos generales mediante
los cuales puede conseguirse esta subdivisión sin modificación de
los programas originales).
\vskip1.000000\baselineskip
El sistema anfitrión 10 crea una base de datos
de estado para sí mismo (la "SDB del anfitrión"). Cada agente
24 crea, también, su propia base de datos de estado (las "SDB del
agente"). La SDB del anfitrión se utiliza para registrar tráfico
por el canal de órdenes cuando se utiliza la realización de
recapitulación del presente invento, para registrar qué fase está
siendo ejecutada, y para registrar información necesaria para el
tratamiento de confirmación de transacciones. Las SDB de agente se
utilizan para registrar información para tratamiento de
recuperación y tratamiento de confirmación de transacciones. En la
realización preferida, una SDB solamente existe en memoria durante
la vida del programa que accede a ella. Sin embargo, todos los
cambios a la SDB son registrados en secuencia en un fichero diario
ordenado (un "registro") en un almacenamiento no volátil, tal
como el sistema 16 de almacenamiento de datos. En cualquier momento,
una SDB puede ser reconstruida en memoria a partir del registro
correspondiente. En la realización preferida, el registro es el
único almacenamiento persistente asociado con una SDB. La
reconstrucción de una SDB se lleva a cabo empezando con una base de
datos vacía y leyendo del registro una serie de cambios en la base
de datos, y reflejando los cambios en el contenido de la base de
datos en memoria.
En la realización preferida, todas las entradas
a una SDB adoptan la forma de un par de cadenas de texto: una clave
y un valor. Cuando se registra una entrada ("Put" =
"Poner"), el programa que llama suministra una entrada de
clave/valor que se almacena en la base de datos. Si existe, antes de
la operación Put, una entrada con una clave idéntica, es
reemplazada. Cuando se lee una entrada ("Get" = "Tomar"),
el programa que llama suministra una clave y, si existe una entrada
que tenga esa clave, se devuelve su cadena de valor. Además, en la
realización preferida, la interconexión de la SDB permite la
creación de listas, que son secuencias de entradas a las que se
puede acceder en secuencia en vez de mediante una clave. Las
entradas Lista son valores de cadena normales.
Un usuario "abre" una SDB aportando el
nombre de un fichero de registro. Si el fichero de registro existe,
es leído y se reconstruye la correspondiente SDB a partir de su
contenido. Si no existe el fichero de registro, se le crea y se
crea una SDB en memoria como estructura de datos vacía. La SDB queda
entonces disponible para realizar operaciones Put y Get hasta que
se la cierra. El cierre de una base de datos se efectúa
explícitamente empleando una operación Close (Cerrar) o,
implícitamente, si deja de existir el programa que accede.
\newpage
En la realización preferida, todas las
operaciones sobre una SDB se agrupan en "transacciones".
Cualquier Put o Get iniciará una nueva transacción si no hay una ya
en progreso. Una transacción continúa a través de subsiguientes
instrucciones de Put y de Get hasta que:
- (1)
- se realiza una operación de confirmación sobre la SDB.
- (2)
- Se realiza una operación de restauración de la SDB, que cancela los efectos de toda la transacción sobre la SDB.
- (3)
- Se cierra la SDB, lo que, implícitamente, devuelve cualesquiera transacciones activas al último estado bueno conocido.
En la realización preferida, las transacciones
sobre una SDB no forman parte de la arquitectura de confirmación
global y tienen una granularidad mucho más fina.
\vskip1.000000\baselineskip
Cuando el programa controlador 14 inicia una
tarea, el sistema anfitrión 10 crea un canal de órdenes 18 para
permitir la comunicación entre el programa controlador 14 y un
programa anfitrión 12. El programa anfitrión 12 trata los datos en
el extremo del sistema anfitrión 10 del canal de órdenes 18. Existe
un programa anfitrión para cada aplicación. El programa anfitrión
12 funciona como sigue:
- (a)
- Inicio de tarea. En la realización preferida, las siguientes funciones son realizadas por el programa anfitrión 12 al comienzo de una aplicación:
- (1)
- ID de la tarea. El programa anfitrión 12 crea un identificador único denominado "ID de la tarea" empleando la dirección de Internet del sistema en el que se ejecuta el programa anfitrión 12, una marca de tiempo y la ID del proceso del programa anfitrión 12.
- (2)
- SBD del anfitrión. El programa anfitrión 12 crea la SDB del anfitrión, utilizando la ID de la tarea como identificador. En la realización preferida, la ID de la tarea se almacena en la SDB del anfitrión.
- (3)
- Fichero de recuperación. El programa anfitrión 12 también graba un fichero denominado "fichero de recuperación" para el sistema 16 de almacenamiento de datos al comienzo de su ejecución. Este fichero también contiene la ID de la tarea, que puede utilizarse para abrir la SDB del anfitrión.
- (b)
- Agentes y nodos remotos. El programa anfitrión 12 inicia procesos y trabaja sobre ficheros/bases de datos a través de uno o más agentes 24. Cada agente 24 establece una conexión bidireccional (un canal 22 de órdenes de agente) con el programa anfitrión 12, para transmitir órdenes al agente 24 y recibir contestaciones del agente 24. Un agente 24 es iniciado en cada sistema remoto 20 donde se ejecutarán programas de aplicación o donde están situados ficheros u otras colecciones de datos. En la realización preferida, los agentes 24 son iniciados sobre una base de acuerdo con las necesidades, en lugar de todos a una al comienzo de una aplicación.
- (c)
- Ejecución de fases. El programa anfitrión 12 utiliza agentes 24 para llevar a la práctica la división de la ejecución de una aplicación sin puntos de control en fases, con dirección del programa controlador 14. El programa anfitrión 12 es responsable de los mecanismos transaccionales que ejecutan esta división y realiza ciertas funciones de coordinación y de contabilidad, como se describe en lo que sigue.
- \quad
- En la realización preferida, las fases se numeran partiendo de cero. Una fase está, siempre, en uno de cuatro "estados": RUNNING (EJECUCIÓN), ERROR, PREPARED (PREPARADA) o COMMITTING (CONFIRMANDO). Cuando se inicia una nueva fase, se encuentra en estado de RUNNING. Continúa en el estado RUNNING en tanto se realicen operaciones remotas durante la fase.
- \quad
- El número de fases en curso y su estado se registran en la SDB del anfitrión. Esta información es registrada en cada transición de estado. En cualquier momento durante la fase, el programa controlador 14 puede invocar la función de vuelta atrás. Esta función hace que se anulen los efectos de todas las operaciones realizadas hasta entonces durante una fase en curso, devolviendo todo estado cambiado al que existía al inicio de la fase y poniendo la fase en el estado de RUNNING.
- \quad
- Durante cada fase, mientras se encuentra en el estado de RUNNING, el programa controlador 14 puede emitir órdenes de iniciar procesos y para llamar a procedimientos remotos (RPC) hacia el programa anfitrión 12. El programa anfitrión 12 envía estas órdenes al agente 24 apropiado, recoge las contestaciones de cada agente 24 y las envía al programa controlador 14. En la realización de recapitulación del presente invento, todas estas órdenes y las réplicas correspondientes son registradas en la SDB del anfitrión. Esta información es utilizada para el "modo de recapitulación" descrito más abajo.
- \quad
- Una vez se ha salido de todos los procesos iniciados por el programa controlador 14, éste puede invocar la función Preparar, poniendo la fase corriente de una aplicación en el estado PREPARED. A continuación de esto, el programa controlador 14 puede invocar la función Confirmar, lo que hace que todos los efectos de todas las operaciones realizadas durante la fase se produzcan completa, correcta e irrevocablemente, finalizando así la fase. También puede llamarse a la función de Vuelta atrás en el estado PREPARED, con el mismo efecto que si la llamada se realizase antes de la función Prepare.
- \quad
- La realización preferida del presente invento hace uso de un protocolo usual de confirmación de dos fases. En la realización de recapitulación preferida, el protocolo de confirmación en dos fases, es como sigue:
- (1)
- Preparar. La orden preparar es ejecutada por el programa anfitrión 12:
- 1)
- Almacenando los datos del canal de órdenes registrados desde la fase corriente en la SDB del anfitrión, empleando una clave que contiene el número de la fase en curso. Si existiese ya dicha información (por ejemplo, debido a una ejecución previa de la misma fase que falló durante el proceso de confirmación), será borrada por la nueva información.
- 2)
- Enviando una orden Preparar desde el programa anfitrión 12 a cada agente 24 que ejecutaba órdenes durante la fase. Cada agente 24, de acuerdo con el protocolo usual de confirmación en dos fases, entra en un estado PREPARED de tal modo que, en cualquier momento subsiguiente, puede ejecutar una orden de Volver atrás que devolverá el estado de todos los recursos bajo control del agente 24, o una orden Confirmar que hará que todos los cambios de todos los recursos bajo control del agente 24, se conviertan en permanentes. Este estado PREPARED debe ser duradero, es decir, debe ser posible reconstruir el estado preparado tras un fallo del sistema y, luego, ejecutar una operación de Volver atrás o de Confirmar. Cuando se ha conseguido el estado PREPARED, cada agente 24 señalará este hecho respondiendo a la orden Preparar.
- 3)
- Esperando que todos los agentes 24 indiquen que se ha completado satisfactoriamente la orden Preparar.
- 4)
- Fijar el estado del programa anfitrión 12 en PREPARED, y tomar nota de ese cambio en la SDB del anfitrión.
- (2)
- Confirmar. La orden Confirmar se lleva a cabo:
- 1)
- Estableciendo el estado del programa anfitrión 12 en COMMITING, y tomar nota de ese cambio en la SDB del anfitrión.
- 2)
- Enviando una orden Confirmar a cada agente 24 que ejecute órdenes durante la fase. Entonces, cada agente 24 hará que todos los cambios en todos los recursos que controla, se conviertan en permanentes, borrando posiblemente información que pudiera haberse requerido en el caso de una vuelta atrás. Cuando dicho tratamiento haya terminado, señalará este hecho respondiendo a la orden Confirmar.
- 3)
- Esperando que todos los agentes 24 indiquen la terminación, con éxito, de la orden Confirmar.
- 4)
- Estableciendo el estado del programa anfitrión 12 en RUNNING, incrementando el número de fase y tomando nota de estos cambios en la SDB de anfitrión.
- \quad
- Durante el estado PREPARED o RUNNING, si una condición de error es detectada por el sistema operativo o por la aplicación, se hará que la fase pase al estado ERROR. En la realización preferida, mientras se encuentra en este estado, no puede realizarse operación remota alguna, ni puede cambiarse el estado de la fase, ni puede iniciarse una nueva fase. En la realización preferida, las únicas acciones legales en este punto son:
- (1)
- Depuración: El programa controlador 14 puede, en forma conocida, utilizar algunas órdenes informativas para depurar la aplicación y/o recopilar información de diagnóstico.
- (2)
- Salida: Cuando sale el programa controlador 14, el programa anfitrión 12 puede intentar la emisión de una orden Volver atrás en nombre del programa controlador 14.
- (3)
- Volver atrás: El programa controlador 14 puede emitir una orden Volver atrás, que pondrá al sistema en su estado de inicio de la fase en curso, deshaciendo cualesquiera cambios en ficheros/bases de datos, como se ha descrito en lo que antecede.
\newpage
- \quad
- En resumen, los cambios de estado legales para el programa anfitrión 12 son los siguientes:
- (1)
- Estado inicial: RUNNING
- (2)
- En cualquier estado que no se COMMITTING, una condición de error provoca una transición al estado ERROR. De este estado se puede salir mediante una orden Restaurar, que pondrá al sistema en el estado RUNNING, o si se sale del programa controlador 14.
- (3)
- En el estado RUNNING, una operación Preparar da lugar a una transición al estado PREPARED. Durante los estados RUNNING o PREPARED, una operación de Vuelta atrás hace que se deshaga la fase, en cuyo caso el número de fase no varía y el sistema realiza, de vuelta, una transición al estado RUNNING.
- (4)
- En el estado PREPARED, una operación Confirmar provoca una transición al estado COMMITTING. Este estado se mantiene mientras dura la operación de Confirmar, luego hace avanzar al número de fase, da por terminada la fase en curso e inicia una nueva fase en el estado RUNNING. Una vez la SDB del anfitrión registra la transición al estado COMMITTING, la detección de un error hará que el sistema aborte. Al volver a ponerse en marcha el sistema, se completará la operación COMMITTING. No es posible una vuelta atrás mientras se está en el estado COMMITING.
- \quad
- Tras completarse (confirmarse) todas las fases de la aplicación, el programa controlador 14 emite una orden Cerrar, que indica que la aplicación se ha completado con éxito. Esta operación borra el fichero de recuperación y la SDB del anfitrión.
- \quad
- En la realización de restauración del presente invento, el procedimiento es similar, pero con varias excepciones. En primer lugar, las órdenes y las contestaciones no se almacenan en la SDB del anfitrión. En lugar de ello, después de ser emitida la orden Preparar por el programa controlador 14 y de ser ejecutada por el programa anfitrión 12 y los agentes 24, se almacena, en forma conocida, un fichero de imagen de memoria del programa controlador 14, de preferencia en un almacenamiento no volátil tal como una unidad de disco. La imagen de memoria comprende todo el espacio de direcciones (incluyendo ficheros de intercambio, etc.) para el programa controlador 14 o solamente las estructuras de datos críticas del programa controlador 14 (según lo determinado por un programador para una ejecución práctica particular del programa controlador 14), necesarias para recrear un estado guardado para el programa controlador 14. Una vez confirmada la grabación del fichero de imagen de memoria (por ejemplo, comparando la imagen del programa todavía en memoria con el fichero de imagen almacenado), y después de que el sistema entra en el estado Preparado, el programa controlador 14 emite la orden Confirmar y el programa anfitrión 12 y los agentes 24 la ejecutan, como en lo que antecede. En la realización preferida, se graba y se confirma un siguiente fichero de imagen de memoria antes de borrarse un fichero de imagen de memoria previo (es decir, se mantienen copias "A" y "B", en forma conocida). Un fichero de imagen de memoria previo solamente debe suprimirse tras haberse completado una operación Confirmar.
- (d)
- Recuperación: Se considera que cualquier aplicación que termine sin haberse ejecutado la operación Cerrar, ha fallado. Cuando se vuelve a poner en marcha la aplicación, se dispara una recuperación. En la realización preferida, siempre que se inicie un programa 12, se comprueba la existencia de un fichero de recuperación. En la realización preferida, si existe el fichero, el programa anfitrión 12 supone que ha ocurrido un fallo anterior y que el intento es para volver a poner en ejecución la tarea anterior.
- \quad
- El primer paso en la recuperación es restaurar todos los ficheros y las bases de datos a su estado más recientemente confirmado. Si la SDB del anfitrión indica un estado de RUNNING, ERROR o PREPARED, entonces el programa anfitrión 12 emite una orden de Vuelta atrás, haciendo, en forma conocida, que se deshagan todas las operaciones sin confirmar. Si la SDB del anfitrión indica un estado RUNNING, el programa anfitrión 12 vuelve a emitir la orden Confirmar, completando la que, evidentemente, fue una operación de Confirmar interrumpida.
- \quad
- En la realización de recapitulación del presente invento, el programa anfitrión 12 entra, entonces, en el modo de recapitulación. Como se ha hecho notar en lo que antecede, el programa controlador 14 interacciona con el resto del sistema a través de un único canal de órdenes 18, cuyo tráfico es almacenado, automáticamente, en la SDB del anfitrión durante el proceso Confirmar, empleando una clave que contiene el número de fase apropiado. Cuando se recapitule la fase, el programa anfitrión 12 empezará recuperando de la SDB del anfitrión el tráfico guardado del canal de órdenes. Para la recapitulación, se vuelve a iniciar el programa controlador 14 a partir de su estado inicial, y funciona normalmente. En el transcurso de la recapitulación, todas las órdenes enviadas por el programa controlador 14 son desechadas por el programa anfitrión 12 (después de, por motivos de seguridad, compararlas con el tráfico de mensajes de órdenes registrado; esto, sin embargo, es opcional). Siempre que el programa controlador 14 espere recibir un mensaje de contestación a través del canal de órdenes 18, el programa anfitrión 12 busca una contestación a partir del tráfico de contestaciones entrantes registradas en el sistema 16 de almacenamiento de datos e inmediatamente proporcionada al programa controlador 14. Debido a la naturaleza determinística de los programas de ordenador de un solo hilo, este proceso tendrá como resultado que el programa controlador 14 ejecute la misma secuencia de órdenes que llevó a cabo durante la ejecución que falló, y el programa de aplicación controlado terminará en el mismo estado en que acabó en la pasada previa.
- \quad
- Cuando se ha reproducido el tráfico del canal de órdenes registrado de todas las fases confirmadas, se garantiza que:
- (1)
- El programa controlador 14 ha sido restaurado (por recapitulación) al estado que adoptó tras la operación Confirmar más reciente; y
- (2)
- Todos los ficheros y las bases de datos han sido, también, restauradas (merced al uso del protocolo de confirmación en dos fases) al estado que habían adoptado tras la operación Confirmar más reciente.
- \quad
- Así, se restablece el estado del sistema y la ejecución puede continuar normalmente.
- \quad
- En la realización de restauración del presente invento, el procedimiento es algo diferente:
- (1)
- Si la SDB del anfitrión indica un estado PREPARED y hay dos ficheros de imagen de memoria guardados (A y B), entonces el programa anfitrión 12 borra el fichero más nuevo (prohibiendo así la posibilidad de una orden de Confirmar duplicada), emite una orden Volver atrás y vuelve a cargar en memoria el fichero de imagen más antiguo (es decir, la última imagen buena guardada, conocida, del programa controlador 14). Si la SDB del anfitrión indica un estado de PREPARED y solamente hay guardado un fichero de imagen de memoria (A o B), entonces el programa anfitrión 12 emite una orden Volver atrás y vuelve a cargar en memoria ese fichero de imagen.
- (2)
- Si la SDB de anfitrión indica un estado RUNNING, entonces el programa anfitrión 12 emite una orden Confirmar y vuelve a cargar en memoria el fichero de imagen más reciente.
- (3)
- Si la SDB de anfitrión indica un estado RUNNING o ERROR y hay guardados dos ficheros de imagen de memoria, entonces el programa anfitrión 12 emite una orden Volver atrás y carga de nuevo en memoria el fichero de imagen más nuevo; si solamente hay guardado un fichero de imagen de memoria, entonces el programa anfitrión 12 emite una orden Volver atrás y carga de nuevo en memoria ese fichero de imagen.
- \quad
- En cualquier caso, el programa anfitrión 12 restablece luego el canal de órdenes 18 y reanuda la ejecución del programa controlador 14.
- \quad
- El protocolo de restauración garantiza que:
- (1)
- Si el fallo se produce antes de entrar en el estado COMMIT, se realiza una Vuelta atrás y se utiliza el fichero de imagen de memoria más antiguo (estado previo a PREPARE). Si el fallo se produce mientras se está en el estado COMMIT, se finaliza la operación Confirmar y se utiliza la imagen de memoria más nueva (estado posterior a PREPARE). Si el fallo se produce después de entrar en el estado COMMIT, se realiza una Vuelta atrás y se utiliza la imagen de memoria más nueva (estado posterior a PREPARE).
- (2)
- Todos los ficheros y las bases de datos han sido restaurados también (mediante el uso, por ejemplo, del protocolo de confirmación en dos fases) al estado en que se encontraban tras la operación Confirmar más reciente.
- \quad
- Así, se restaura el estado del sistema y la ejecución puede continuar normalmente.
\vskip1.000000\baselineskip
La descripción que sigue se aplica a cada agente
24 iniciado por el programa anfitrión 12. La expresión "nodo
local" se utiliza para indicar el sistema en el que se está
ejecutando un agente 24 particular.
Cada agente 24 realiza las operaciones reales
necesarias para ejecutar una aplicación. Un agente 24 es responsable
de la realización de las operaciones sólo en el sistema remoto 20
en el que se está ejecutando. Estas operaciones incluyen la
ejecución de llamadas a procedimientos remotos, la confirmación y la
vuelta atrás de tales operaciones y procesos de creación y de
vigilancia. Puede considerarse que un agente 24 reside "entre"
una aplicación y el sistema operativo en el sentido de que un
agente 24 controla cuándo y cómo puede ejecutarse una
aplicación.
Las órdenes son enviadas por el programa
controlador 14 a un agente 24 a través del programa anfitrión 12 en
forma de llamadas a procedimientos remotos (RPC). En la realización
preferida, una orden RPC consiste en un identificador seguido por
una serie de argumentos, todos los cuales son cadenas de texto. El
agente 24 contiene una tabla que correlaciona los identificadores
de órdenes RPC con "gestionadores de RPC", siendo un
gestionador un objeto que permite la invocación de
sub-rutinas para realizar la RPC, confirmar la RPC,
y volver atrás la RPC. El agente 24 gestiona, así, la RPC
localizando el gestionador de RPC apropiado, proporcionando luego a
ese gestionador de RPC los argumentos de la RPC. La rutina de
gestión de la RPC analiza sintácticamente las cadenas de argumentos
y realiza la operación requerida. A continuación, la rutina de
gestión de la RPC produce una cadena de contestación que es enviada
de vuelta al programa controlador 14 a través del programa
anfitrión 12. Cada cadena de contestación incluye información sobre
el éxito de la orden y cualquier dato devuelto solicitado. En la
realización preferida, se utiliza una RPC especial para iniciar
procesos, como se explica en lo que sigue.
Cuando se inicia un agente 24, la primera orden
de RPC que recibe es una orden Iniciar agente. Esta orden notifica
al agente 24 la ID de la tarea para la aplicación y asigna al nodo
local una "ID de nodo" única. El agente 24 abre entonces una
base de datos de estado denominada la "SDB del agente". El
nombre de la SDB del agente se deriva de la ID de la tarea y de la
ID del nodo y es, asimismo, único en toda la aplicación.
Cada agente 24 sigue las fases de la aplicación
junto con el programa anfitrión 12. Cuando el programa anfitrión 12
realiza una operación Preparar o Confirmar, lo hace enviando órdenes
RPC de Preparar nodo y Confirmar nodo, a cada uno de sus agentes
24. En las realizaciones preferidas, el programa controlador 14
solamente considerará que la aplicación en conjunto está en estado
PREPARED una vez que todos los agentes 24 han respondido
satisfactoriamente a sus órdenes Preparar Nodo individuales.
Similarmente, la aplicación sólo considerará confirmada una fase y
avanzará a la fase siguiente, cuando todos los agentes 24 hayan
respondido satisfactoriamente a sus órdenes Confirmar Nodo.
Cada agente 24 registra la fase en curso y su
estado en su SDB del agente. Los cuatro estados definidos y los
cambios de estado permitidos son como en el programa anfitrión 12 y,
en el caso normal, siguen a los del programa anfitrión 12. El
estado de fase en curso (y el número de fase en curso) pueden
recuperarse mediante el programa controlador 14 utilizando una
orden RPC "NodeState" ("EstadodeNodo").
Cuando el programa controlador 14 invoca la
función Cerrar, emite una orden Cerrar a cada agente 24. Cada
agente 24 responde verificando que el estado de fase local es en
ejecución y que no se están ejecutando procesos y, luego, borra su
SDB del agente asociada.
En la realización preferida, cada agente 24
realiza operaciones de RPC que son parte de la fase y, por tanto,
están sometidas a la arquitectura confirmar/volver atrás. Para hacer
esto, cada agente 24 hace uso de su SDB del agente.
Específicamente, para cada fase, un agente 24 crea, en su SDB del
agente, una lista denominada la "CR_LIST" (LISTA_CR) en la que
se realiza una entrada por cada operación. En forma conocida, cada
entrada contiene información suficiente para deshacer la operación.
La lista está ordenada, de preferencia, de modo que las operaciones
puedan deshacerse en orden inverso a aquél en que se realizaron.
En la realización preferida, por uniformidad,
todas las RPC deben estar en conformidad con las siguientes
restricciones:
- (1)
- Si una RPC cambia el estado de un fichero/base de datos, debe guardar cualquier información que pueda ser necesaria para deshacer todos los cambios y volver atrás en ese fichero/base de datos, y crear una entrada en la CR_LIST. Esta entrada debe contener la identidad de la orden de RPC que se está ejecutando, de manera que pueda localizarse el gestionador de RPC apropiado durante el proceso de confirmación/vuelta atrás.
- (2)
- Cada gestionador de RPC debe proporcionar medios para llevar a la práctica las operaciones de Preparar, Confirmar y Volver atrás (que pueden ser operaciones nulas si la RPC no realiza cambios ni en base de datos ni en fichero alguno).
- (3)
- Cada gestionador de RPC puede utilizar, opcionalmente, la SDB de cada agente 24 para almacenar cualquier información necesaria para satisfacer estos requisitos.
- (4)
- No se requiere acción especial alguna para las RPC que no cambien el estado de ficheros ni de bases de datos.
\vskip1.000000\baselineskip
En la realización preferida, los programas de
aplicación deben obedecer las siguientes reglas:
- (1)
- Si un proceso modifica ficheros/bases de datos, debe proporcionar medios para deshacer los cambios y para llevar a la práctica las operaciones de Preparar/Confirmar/Volver atrás. Los procesos bajo el control de un agente 24 tienen, también, acceso a las SDB del agente. Por ejemplo, el programa de aplicación puede crear entradas en la CR_LIST. Tales entradas deben contener el identificador para una orden RPC que lleve a la práctica las apropiadas operaciones de confirmación/vuelta atrás. Sin embargo, en este caso, una RPC no tiene lugar realmente, de forma que se introduce un identificador para una "RPC falsa".
- (2)
- Alternativamente, el programa controlador 14 puede emitir varias RPC en nombre de un proceso que tendrán el mismo efecto.
\vskip1.000000\baselineskip
La orden Iniciar Proceso para el agente 24 hace
que el agente 24 ejecute un fichero de imagen de programa de
aplicación especificado, poniendo así en marcha un "proceso" en
el nodo local. En la realización preferida, los argumentos para
esta orden aportan:
- (1)
- El fichero imagen ejecutable para el programa
- (2)
- La lista de argumentos del programa.
- (3)
- Cualquier información sobre el entorno del sistema operativo, requerida por el programa.
- (4)
- Ficheros o vías de acceso que han de ser abiertas en el proceso para uso como entrada, salida y canales de error estándar.
- (5)
- El código de estado de salida con el que el programa debe salir para indicar una ejecución satisfactoria.
- (6)
- Un modo de depuración (la depuración se describe más adelante).
\vskip1.000000\baselineskip
Cada agente 24 mantiene una lista de todos los
procesos que se encuentran bajo su control. A medida que se inician
los procesos, se añaden a esta lista los identificadores para esos
procesos.
En la realización preferida, cada agente 24 no
espera la terminación de un proceso antes de contestar al programa
controlador 14. Cada agente 24 permite que el proceso se ejecute
concurrentemente con el agente 24, al tiempo que vigila la
ejecución del proceso. En todo momento, un agente 24 está al
corriente del "estado del proceso" que, en la realización
preferida es uno de entre PS_RUNNING (PS_EJECUTÁNDOSE), PS_ERROR,
PS_DEBUG (PS_DEPURACIÓN) o PS_EXITED (PS_HA_SALIDO).
El estado PS_RUNNING indica que se está
ejecutando un proceso de un programa sin problemas conocidos. El
estado PS_ERROR indica que se sabe que el proceso ha encontrado un
problema irresoluble y, (1) ha señalado una condición de error (una
señal o una trampa de error), o (2) ha salido con un estado de error
indicativo de un fallo, o (3) ha salido de forma anormal (por
ejemplo, abortando o siendo terminado manualmente por un operador).
El estado PS_EXITED indica que el proceso ha completado
satisfactoriamente su ejecución y ha terminado por sí mismo
normalmente. El estado PS_DEBUG se describe en el apartado
"depuración" en lo que sigue.
En la realización preferida, el programa
controlador 14 puede preguntar el estado de un proceso empleando
una orden RPC "ProcState" ("EstadodeProceso"). Cada agente
24 mantiene, también, un estado de proceso agregado que indica el
estado de todos los procesos que se le ha ordenado iniciar en
conjunto. Este estado agregado se denomina "estado de proceso de
nodo" y es diferente del estado confirmar/volver atrás del nodo
(RUNNING, PREPARED, COMMITTING, ERROR). Los estados de proceso de
nodo son los mismos que los cuatro estados de proceso y se definen
como sigue:
- (1)
- si algún proceso se encuentra en el estado PS_DEBUG, entonces el estado agregado es PS_DEBUG, de otro modo,
- (2)
- si cualquier proceso se encuentra en el estado PS_ERROR, entonces el estado agregado es PS_ERROR, de otro modo,
- (3)
- si cualquier proceso se encuentra en el estado PS_RUNNING, entonces el estado agregado es PS_RUNNING, de otro modo,
- (4)
- el estado agregado es PS_EXITED (todos los procesos han terminado y se ha salido de ellos normalmente).
Las transiciones del estado de proceso de nodo
afectan al estado confirmar/volver atrás del nodo. Específicamente,
si el estado de proceso de nodo pasa al estado PS_ERROR, entonces el
estado confirmar/volver atrás del nodo pasará, automáticamente, al
estado ERROR. Además, solamente es legal pasar del estado RUNNING al
estado PREPARED, o del estado PREPARED al estado RUNNING, si el
estado de proceso es PS_EXITED.
El estado de proceso agregado puede ser
recuperado por el programa controlador 14 utilizando la orden
NodeState (Estado de nodo) del agente.
En la realización preferida, los procesos pueden
emitir mensajes de error a través de canales de E/S de error
estándar. Por ejemplo, en UNIX, este es el fichero de E/S
"stderr". Tal salida puede ser encaminada, opcionalmente, al
agente 24 desde cualquier proceso, y está disponible para el
programa controlador 14 a través de la orden RPC "Eread".
El programa controlador 14 tropieza,
frecuentemente, con una circunstancia en la que no puede continuar
su ejecución hasta que todos los procesos iniciados en un nodo o
grupo de nodos, hayan sido ejecutados por completo. Para acomodar
esta circunstancia, el agente 24 soporta una orcen "Wait"
(Esperar) procedente del programa controlador 14. La orden Esperar
hace que un agente 24 retrase su constelación hasta que el estado de
proceso de nodo deja de estar en el estado PS_RUNNING (es decir, el
estado es PS_DEBUG, PS_ERROR o PS_EXITED). La contestación a la
orden Esperar indica a los procesos que han originado la condición
Esperar que terminen. El programa controlador 14 puede cancelar,
también, la condición Esperar enviando una orden RPC "Sync"
("Sinc") al agente 24 durante la condición Esperar. La orden
Sinc tanto si se ha recibido accidentalmente una contestación a la
espera como si no (porque la contestación a esperar y la orden sinc
se cruzan en el canal de órdenes 18).
\vskip1.000000\baselineskip
De vez en cuando, resulta útil que el programa
controlador 14 le permita al usuario realizar la depuración de un
proceso particular del sistema. La depuración supone poner en marcha
un proceso bajo el control de un depurador estándar, como el
disponible en cualquier sistema operativo particular. Un usuario
puede querer depurar un proceso desde el comienzo de su ejecución.
Alternativamente, el usuario puede querer depurar un proceso
solamente si encuentra una condición de error, es decir, cuando el
proceso cambia al estado de proceso PS_ERROR.
En la realización preferida, cuando se pone en
marcha un proceso (utilizando la orden Iniciar Proceso), puede
especificarse su ejecución en cualquiera de tres "modos de
depuración": DEBUG_NONE (NO_DEPURAR), DEBUG_START
(DEPURAR_DESDE_INICIO) y DEBUG_TRACE (SEGUIR_DEPURACIÓN). En un
programa que se encuentre en el modo de depuración DEBUG_NONE no se
ejecutará el depurador. Los procesos en que se especifique el modo
DEBUG_START se ejecutarán desde el comienzo con un depurador
asociado. Los procesos en que se especifique el modo DEBUG_TRACE,
serán vigilados por el agente 24 y, si entrasen en cualquiera de
varias condiciones de error detectables (que pueden incluir trampas
de error, señales o decisiones de abortar), serán detenidos y se
ejecutará un depurador en asociación con el proceso que falla.
En la realización preferida, un agente 24 no
inicia el depurador en forma autónoma. En vez de ello, cuando hay
necesidad de depurar un proceso (según se indica mediante el modo
depurar), el agente 24 pasa el proceso al estado de proceso
PS_DEBUG. Esto hace que el estado de proceso agregado pase a
PS_DEBUG. Este estado se le comunica al programa controlador 14
(por ejemplo, este estado hace que finalice una condición de
espera). En ese momento, el programa controlador 14 puede invocar
un depurador para el proceso utilizando una orden RPC
"depurar". Esta orden especifica un programa a ejecutar,
presumiblemente, un guión de órdenes, al que se le pasará
información suficiente (a través de la lista de argumentos) para
iniciar un depurador elegido.
\vskip1.000000\baselineskip
Cada agente mantiene un estado y un número de
fase local que se almacenan en su SDB del agente. El número de fase
es mantenido en sincronismo con el del programa anfitrión 12
mediante el protocolo preparar/confirmar. El estado de fase se
deriva, principalmente, del estado de proceso y es utilizado por el
programa controlador 14 para calcular el estado de la fase en curso
para la aplicación en su conjunto.
Cuando el programa controlador 14 es vuelto a
invocar tras un fallo, le dice al programa anfitrión 12 que inicie
una tarea. Si se encuentra un "fichero de recuperación",
entonces el programa anfitrión 12 entra en el "modo de
recuperación" y recupera el estado de los agentes 24 como
sigue:
- (1)
- Se utiliza la SDB del anfitrión para determinar el conjunto de procesos de agente 24 en ejecución en el momento del fallo.
- (2)
- Se crea un nuevo agente 24 en cada uno de tales nodos.
- (3)
- Cada agente 24 recibe una orden "Iniciar Agente" con la ID de tarea.
- (4)
- Los agentes 24 reconocen esta ID de tarea como una aplicación existente, porque la SDB del agente todavía existe (su nombre se deriva de la ID de la tarea).
- (5)
- Cada agente 24 abre su SDB, que se ha reconstruido a partir de su registro, y extrae el estado, el número de fase en curso y la lista confirmar-volver atrás.
- (6)
- Si el programa anfitrión 12 está en un estado distinto de COMMITTING, transmitirá entonces una orden de Vuelta atrás a los agentes 24 que hará que los agentes 24 deshagan, en orden inverso, todas las operaciones realizadas en esa fase. Si, por otro lado, el programa anfitrión 12 estaba en el estado COMMITTING, volverá a emitir una orden Confirmar a los agentes 24. Cualquier agente 24 que se encuentre en estado COMMITTING completará lo que, evidentemente, era una operación de confirmación interrumpida recorriendo la lista de confirmar-volver atrás en orden directo, ejecutando los métodos de confirmación de todas las entradas. Cualquier agente 24 que se encuentre, a su vez, en estado RUNNING, tratará la orden Confirmar como una orden Nula (ya que, evidentemente, la anterior operación de Confirmación se había completado en este nodo pero no en algunos otros nodos).
- (7)
- En ese punto, los agentes 24 consideran que, ellos mismos, se encuentran al inicio de esa fase en el estado RUNNING, y pueden proceder a aceptar órdenes del programa controlador 14.
\vskip1.000000\baselineskip
La figura 4 es una gráfica de flujo que muestra,
en forma resumida, las operaciones funcionales básicas de la
realización de recapitulación del presente invento. El programa
controlador 14 inicia procesos en los sistemas remotos 20 (Paso
40). El programa anfitrión 12 registra todas las órdenes de control
procedentes del programa controlador 14 (Paso 41), así como todas
las contestaciones al programa controlador 14 (Paso 42). Cada agente
24 ejecuta una aplicación en fases en su respectivo sistema remoto
20 (Paso 43). Las aplicaciones ejecutan un protocolo
preparar-confirmar para almacenar estados de
ficheros y de sistemas mientras mantienen la consistencia del
sistema (Paso 44). Si se produce un fallo, se restaura el estado del
sistema y se reinicia el programa controlador 14, emitiéndose
órdenes al programa anfitrión 12 (Paso 45). El programa anfitrión 12
lee las contestaciones coincidentes para cada orden y envía las
contestaciones al programa controlador 14, en un modo de
recapitulación, hasta el final (Paso 46). El programa controlador
14 continúa controlando entonces los procesos de aplicación a
partir del último punto de control bueno (Paso 47).
La figura 5 es un diagrama de flujo que muestra,
en forma resumida, las operaciones funcionales básicas de la
realización de restauración del presente invento. El programa
controlador 14 inicia procesos en sistemas remotos 20 (Paso 50).
Cada agente 24 ejecuta una aplicación en fases en su respectivo
sistema remoto 20 (Paso 51). Las aplicaciones ejecutan la parte de
preparación de un protocolo de confirmación para almacenar estados
de ficheros y de sistemas (Paso 52). Se almacena una imagen de
memoria del programa controlador 14 después de terminado el
protocolo de preparación (Paso 53). Las aplicaciones ejecutan un
protocolo de confirmación para completar el almacenamiento seguro
de los estados de ficheros y de sistemas, al tiempo que mantienen
la consistencia del sistema (Paso 54). Si se produce un fallo, se
restaura el estado del sistema y la imagen de memoria almacenada
del programa controlador 14 es cargada de nuevo en memoria (Paso
55). El programa controlador 14 continúa entonces controlando los
procesos de aplicación a partir del último punto de control bueno
(Paso 56).
Se han descrito varias realizaciones del
presente invento. No obstante, se comprenderá que pueden realizarse
diversas modificaciones sin por ello apartarse del espíritu ni del
alcance del presente invento. Por ejemplo, el invento podría
aplicarse a sistemas con una sola CPU. Además, si bien se prefiere
un protocolo de confirmación en dos fases, pueden utilizarse otros
protocolos de confirmación que guarden en forma segura el estado del
sistema al tiempo que mantienen la consistencia del mismo. En
consecuencia, se comprenderá que el invento no ha de considerarse
limitado por la realización específica ilustrada, sino solamente por
el alcance de las reivindicaciones adjuntas.
Claims (20)
1. Un método para ejecutar una aplicación de
ordenador en un sistema de tratamiento en paralelo, en el que dicha
aplicación carece de la posibilidad de establecer puntos de control
previamente programados, que comprende los pasos de:
- \quad
- ejecutar una aplicación en una serie de fases de ejecución en un sistema de tratamiento en paralelo, de tal forma que los procesos de la aplicación estén inactivos entre fases de ejecución;
- \quad
- controlar el tratamiento de cada fase de ejecución, incluyendo la creación de instancias y la vigilancia de todos los programas y colecciones de datos que formen la aplicación;
- \quad
- guardar el estado final de cada fase de ejecución terminada con éxito;
- \quad
- detectar un fallo de la aplicación en cualquiera de tales fases de ejecución;
- \quad
- restaurar el último estado final guardado de la fase de ejecución antes de la fase de ejecución en que se detectó el fallo; y
- \quad
- reiniciar la aplicación al comienzo de la fase de ejecución en que se detectó el fallo.
2. El método de la reivindicación 1, en el que
los programas de vigilancia y de creación de instancias y las
colecciones de datos que forman la aplicación, incluyen la emisión
de órdenes y la recepción de contestaciones a tales órdenes.
3. El método de la reivindicación 2, que
incluye, además, registrar todas las citadas órdenes y las
contestaciones a dichas órdenes.
4. El método de la reivindicación 3, en el que
la restauración del último estado final guardado en la fase de
ejecución previa a la fase de ejecución en que se detectó un fallo,
incluye recapitular todas las órdenes y las contestaciones a tales
órdenes registradas desde el comienzo de la ejecución de la
aplicación hasta el último estado final guardado de la fase de
ejecución previa a la fase de ejecución en que se detectó el
fallo.
5. El método de la reivindicación 1, en el que
los programas de vigilancia y de creación de instancias y las
colecciones de datos que forman la aplicación, incluyen programas de
vigilancia que se ejecutan en diferentes partes del sistema de
tratamiento en paralelo utilizando un programa controlador (14).
6. El método de la reivindicación 5, que incluye
además, al término de cada fase de ejecución completada con éxito,
guardar al menos las estructuras de datos del programa controlador
necesarias para recrear un estado guardado para el programa
controlador.
7. El método de la reivindicación 6, en el que
la restauración del último estado final guardado de la fase de
ejecución previa a la fase de ejecución en que se detectó el fallo,
incluye restaurar el programa controlador volviendo a cargar en
memoria las estructuras de datos guardadas del programa controlador
hasta el término de la fase de ejecución previa a la fase de
ejecución en que se detectó el fallo.
8. El método de la reivindicación 1, en el que
se guarda el estado final de cada fase de ejecución completada con
éxito después de esperar hasta que los procesos iniciados en la fase
de ejecución se han completado y no hay transferencias de datos
pendientes entre diferentes partes del sistema de tratamiento en
paralelo.
9. El método de la reivindicación 1, en el que
el estado final de cada fase de ejecución completada con éxito se
guarda mediante un protocolo de confirmación en dos fases.
10. El método de la reivindicación 1, que
incluye además emitir, repetidamente, una orden de espera para
suspender la operación con el fin de dar tiempo a que se completen
los procesos, incluyendo las transferencias de datos pendientes
antes de guardar el estado final de cada fase de ejecución
completada satisfactoriamente.
11. Un medio de almacenamiento legible por
ordenador, configurado con un programa de ordenador para ejecutar
una aplicación de ordenador en un sistema de tratamiento en
paralelo, en el que tal aplicación carece de la capacidad de crear
puntos de control previamente programados, cuyo medio de
almacenamiento está configurado para hacer que un ordenador
funcione de manera específica y predefinida a fin de realizar las
funciones de:
- \quad
- ejecutar una aplicación en una serie de fases de ejecución en un sistema de tratamiento en paralelo, de tal manera que los procesos de la aplicación estén inactivos entre fases de ejecución;
- \quad
- controlar el tratamiento de cada fase de ejecución incluyendo la vigilancia y la creación de instancias de todos los programas y colecciones de datos que forman la aplicación;
- \quad
- guardar el estado final de cada fase de ejecución completada con éxito;
- \quad
- detectar un fallo de la aplicación en cualquiera de tales fases de ejecución;
- \quad
- restaurar el último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo; y
- \quad
- reiniciar la aplicación al comienzo de la fase de ejecución en que se detectó el fallo.
12. El medio de almacenamiento legible por
ordenador de la reivindicación 11, en el que los programas de
vigilancia y creación de instancias y las colecciones de datos que
forman la aplicación, incluyen la emisión de órdenes y la recepción
de contestaciones a tales órdenes.
13. El medio de almacenamiento legible por
ordenador de la reivindicación 12, para realizar, además, la función
de registrar todas las mencionadas órdenes y contestaciones de
tales órdenes.
14. El medio de almacenamiento legible por
ordenador de la reivindicación 13, en el que la restauración del
último estado final guardado de la fase de ejecución previa a la
fase de ejecución en que se detectó el fallo, incluye recapitular
todas las órdenes y las contestaciones a tales órdenes registradas,
desde el comienzo de la ejecución de la aplicación hasta el último
estado final guardado de la fase de ejecución previa a la fase de
ejecución en que se detectó el fallo.
15. El medio de almacenamiento legible por
ordenador de la reivindicación 11, en el que los programas de
vigilancia y creación de instancias y las colecciones de datos que
forman la aplicación, incluyen programas de vigilancia que se
ejecutan en diferentes partes del sistema de tratamiento en paralelo
utilizando un programa de control (14).
16. El medio de almacenamiento legible por
ordenador de la reivindicación 15, para realizar, además, la función
de, al término de cada fase de ejecución completada
satisfactoriamente, guardar al menos las estructuras de datos del
programa controlador necesarias para recrear un estado guardado para
el programa de control.
17. El medio de almacenamiento legible por
ordenador de la reivindicación 16, en el que la restauración del
último estado final guardado de la fase de ejecución previa a la
fase de ejecución en que se detectó el fallo, incluye restaurar el
programa controlador volviendo a cargar en memoria la estructura de
datos guardada del programa controlador hasta el término de la fase
de ejecución previa a la fase de ejecución en se detectó el
fallo.
18. El medio de almacenamiento legible por
ordenador de la reivindicación 11, en el que se guarda el estado
final de cada fase de ejecución completada satisfactoriamente,
después de esperar hasta que los procesos iniciados en la fase de
ejecución se hayan completado y no queden transferencias de datos
pendientes entre diferentes partes del sistema de tratamiento en
paralelo.
19. El medio de almacenamiento legible por
ordenador de la reivindicación 11, en el que el estado final de
cada fase de ejecución completada con éxito se guarda mediante un
protocolo de confirmación en dos fases.
20. El medio de almacenamiento legible por
ordenador de la reivindicación 11, para realizar, además, la función
de emitir, repetidamente, una orden de espera para suspender la
operación con el fin de dar tiempo a que se completen los procesos
incluyendo transferencias de datos pendientes antes de guardar el
estado final de cada fase de ejecución completada
satisfactoriamente.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/570,724 US5712971A (en) | 1995-12-11 | 1995-12-11 | Methods and systems for reconstructing the state of a computation |
US570724 | 1995-12-11 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2320601T3 true ES2320601T3 (es) | 2009-05-25 |
Family
ID=24280795
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES96943730T Expired - Lifetime ES2320601T3 (es) | 1995-12-11 | 1996-12-11 | Metodo para reconstruir el estado de un calculo. |
Country Status (11)
Country | Link |
---|---|
US (1) | US5712971A (es) |
EP (1) | EP0954779B8 (es) |
JP (2) | JP3573463B2 (es) |
AT (1) | ATE423351T1 (es) |
AU (1) | AU1288897A (es) |
CA (1) | CA2240347C (es) |
DE (1) | DE69637836D1 (es) |
DK (1) | DK0954779T3 (es) |
ES (1) | ES2320601T3 (es) |
PT (1) | PT954779E (es) |
WO (1) | WO1997022052A1 (es) |
Families Citing this family (138)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5931954A (en) * | 1996-01-31 | 1999-08-03 | Kabushiki Kaisha Toshiba | I/O control apparatus having check recovery function |
GB2311391A (en) * | 1996-03-19 | 1997-09-24 | Ibm | Restart and recovery of OMG compliant transaction systems |
US5909681A (en) | 1996-03-25 | 1999-06-01 | Torrent Systems, Inc. | Computer system and computerized method for partitioning data for parallel processing |
US6324567B2 (en) * | 1997-06-11 | 2001-11-27 | Oracle Corporation | Method and apparatus for providing multiple commands to a server |
AU8674098A (en) * | 1997-07-31 | 1999-02-22 | Data Net Corporation | Method and apparatus for implementing software connectivity for client/server applications |
US6009258A (en) * | 1997-09-26 | 1999-12-28 | Symantec Corporation | Methods and devices for unwinding stack of frozen program and for restarting the program from unwound state |
US5911060A (en) * | 1997-09-26 | 1999-06-08 | Symantec Corporation | Computer method and apparatus for unfreezing an apparently frozen application program being executed under control of an operating system |
US6029177A (en) * | 1997-11-13 | 2000-02-22 | Electronic Data Systems Corporation | Method and system for maintaining the integrity of a database providing persistent storage for objects |
JPH11282684A (ja) * | 1998-03-27 | 1999-10-15 | Canon Inc | 画像処理装置、画像処理装置の制御方法、および記憶媒体 |
US6477663B1 (en) * | 1998-04-09 | 2002-11-05 | Compaq Computer Corporation | Method and apparatus for providing process pair protection for complex applications |
US6175932B1 (en) * | 1998-04-20 | 2001-01-16 | National Instruments Corporation | System and method for providing state capture and restoration to an I/O system |
US8631066B2 (en) * | 1998-09-10 | 2014-01-14 | Vmware, Inc. | Mechanism for providing virtual machines for use by multiple users |
US6397351B1 (en) | 1998-09-28 | 2002-05-28 | International Business Machines Corporation | Method and apparatus for rapid data restoration including on-demand output of sorted logged changes |
US6226759B1 (en) | 1998-09-28 | 2001-05-01 | International Business Machines Corporation | Method and apparatus for immediate data backup by duplicating pointers and freezing pointer/data counterparts |
US6256751B1 (en) * | 1998-10-29 | 2001-07-03 | International Business Machines Corporation | Restoring checkpointed processes without restoring attributes of external data referenced by the processes |
US6338147B1 (en) | 1998-10-29 | 2002-01-08 | International Business Machines Corporation | Program products for performing checkpoint/restart of a parallel program |
US6393583B1 (en) | 1998-10-29 | 2002-05-21 | International Business Machines Corporation | Method of performing checkpoint/restart of a parallel program |
US6401216B1 (en) | 1998-10-29 | 2002-06-04 | International Business Machines Corporation | System of performing checkpoint/restart of a parallel program |
EP1185928A1 (en) | 1998-12-16 | 2002-03-13 | Kent Ridge Digital Labs | Process oriented computing environment |
US7047232B1 (en) * | 1999-01-13 | 2006-05-16 | Ab Initio Software Corporation | Parallelizing applications of script-driven tools |
JP4237354B2 (ja) * | 1999-09-29 | 2009-03-11 | 株式会社東芝 | トランザクション処理方法及びトランザクション処理システム |
US6630946B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods for automatically locating data-containing windows in frozen applications program and saving contents |
US6631480B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods and systems for protecting data from potential corruption by a crashed computer program |
US6662310B2 (en) | 1999-11-10 | 2003-12-09 | Symantec Corporation | Methods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data |
US6584581B1 (en) * | 1999-12-06 | 2003-06-24 | Ab Initio Software Corporation | Continuous flow checkpointing data processing |
US6678701B1 (en) | 2000-01-05 | 2004-01-13 | International Business Machines Corporation | Technique for establishing a point of consistency in a parallel database loading system |
EP1128266A3 (en) * | 2000-02-22 | 2004-02-25 | Orsus Solutions Limited | Cooperative software application architecture |
TW525329B (en) * | 2000-05-29 | 2003-03-21 | Omron Tateisi Electronics Co | Power supply module and power supply unit using the same |
US6944790B2 (en) * | 2001-04-05 | 2005-09-13 | International Business Machines Corporation | System and method for collecting and restoring user environment data using removable storage |
US8234156B2 (en) * | 2001-06-28 | 2012-07-31 | Jpmorgan Chase Bank, N.A. | System and method for characterizing and selecting technology transition options |
US6883114B2 (en) * | 2001-11-08 | 2005-04-19 | M-Systems Flash Disk Pioneers Ltd. | Block device driver enabling a ruggedized file system |
KR20030056540A (ko) * | 2001-12-28 | 2003-07-04 | 한국전자통신연구원 | 데이터베이스 관리 시스템에서 시스템 고장에 대비한 파일삭제 및 회복 방법 |
US7168008B2 (en) * | 2002-01-18 | 2007-01-23 | Mobitv, Inc. | Method and system for isolating and protecting software components |
US6880051B2 (en) * | 2002-03-14 | 2005-04-12 | International Business Machines Corporation | Method, system, and program for maintaining backup copies of files in a backup storage device |
GB0211179D0 (en) * | 2002-05-16 | 2002-06-26 | Ibm | A method,apparatus and computer program for reducing the amount of data checkpointed |
US7024591B2 (en) * | 2002-07-12 | 2006-04-04 | Crossroads Systems, Inc. | Mechanism for enabling enhanced fibre channel error recovery across redundant paths using SCSI level commands |
US20040083158A1 (en) * | 2002-10-09 | 2004-04-29 | Mark Addison | Systems and methods for distributing pricing data for complex derivative securities |
US7167850B2 (en) * | 2002-10-10 | 2007-01-23 | Ab Initio Software Corporation | Startup and control of graph-based computation |
US7340650B2 (en) * | 2002-10-30 | 2008-03-04 | Jp Morgan Chase & Co. | Method to measure stored procedure execution statistics |
US7149752B2 (en) * | 2002-12-03 | 2006-12-12 | Jp Morgan Chase Bank | Method for simplifying databinding in application programs |
US7085759B2 (en) | 2002-12-06 | 2006-08-01 | Jpmorgan Chase Bank | System and method for communicating data to a process |
US8032439B2 (en) * | 2003-01-07 | 2011-10-04 | Jpmorgan Chase Bank, N.A. | System and method for process scheduling |
US7401156B2 (en) * | 2003-02-03 | 2008-07-15 | Jp Morgan Chase Bank | Method using control interface to suspend software network environment running on network devices for loading and executing another software network environment |
US7484087B2 (en) * | 2003-02-24 | 2009-01-27 | Jp Morgan Chase Bank | Systems, methods, and software for preventing redundant processing of transmissions sent to a remote host computer |
JP4345334B2 (ja) * | 2003-03-28 | 2009-10-14 | 日本電気株式会社 | 耐障害計算機システム、プログラム並列実行方法およびプログラム |
US7379998B2 (en) * | 2003-03-31 | 2008-05-27 | Jp Morgan Chase Bank | System and method for multi-platform queue queries |
US20040230602A1 (en) * | 2003-05-14 | 2004-11-18 | Andrew Doddington | System and method for decoupling data presentation layer and data gathering and storage layer in a distributed data processing system |
US7366722B2 (en) * | 2003-05-15 | 2008-04-29 | Jp Morgan Chase Bank | System and method for specifying application services and distributing them across multiple processors using XML |
US7509641B2 (en) * | 2003-05-16 | 2009-03-24 | Jp Morgan Chase Bank | Job processing framework |
US7634500B1 (en) | 2003-11-03 | 2009-12-15 | Netlogic Microsystems, Inc. | Multiple string searching using content addressable memory |
EP1690163A4 (en) * | 2003-11-17 | 2011-07-13 | Virginia Tech Intell Prop | TRANSPARENT CREATION OF CONTROL POINTS AND MIGRATION OF PROCESSES IN A DISTRIBUTED SYSTEM |
US7281023B2 (en) * | 2003-12-15 | 2007-10-09 | At&T Knowledge Ventures, L.P. | Architecture of database application with robust online recoverability |
US20050144174A1 (en) * | 2003-12-31 | 2005-06-30 | Leonid Pesenson | Framework for providing remote processing of a graphical user interface |
US8689185B1 (en) * | 2004-01-27 | 2014-04-01 | United Services Automobile Association (Usaa) | System and method for processing electronic data |
US8140348B2 (en) * | 2004-01-30 | 2012-03-20 | International Business Machines Corporation | Method, system, and program for facilitating flow control |
US7650606B2 (en) * | 2004-01-30 | 2010-01-19 | International Business Machines Corporation | System recovery |
US7366801B2 (en) * | 2004-01-30 | 2008-04-29 | International Business Machines Corporation | Method for buffering work requests |
US7702767B2 (en) * | 2004-03-09 | 2010-04-20 | Jp Morgan Chase Bank | User connectivity process management system |
US9734222B1 (en) | 2004-04-06 | 2017-08-15 | Jpmorgan Chase Bank, N.A. | Methods and systems for using script files to obtain, format and transport data |
US20050222990A1 (en) * | 2004-04-06 | 2005-10-06 | Milne Kenneth T | Methods and systems for using script files to obtain, format and disseminate database information |
AU2005234798B2 (en) * | 2004-04-26 | 2009-01-08 | Jp Morgan Chase Bank | System and method for routing messages |
US7665127B1 (en) | 2004-06-30 | 2010-02-16 | Jp Morgan Chase Bank | System and method for providing access to protected services |
US7386752B1 (en) * | 2004-06-30 | 2008-06-10 | Symantec Operating Corporation | Using asset dependencies to identify the recovery set and optionally automate and/or optimize the recovery |
US7392471B1 (en) | 2004-07-28 | 2008-06-24 | Jp Morgan Chase Bank | System and method for comparing extensible markup language (XML) documents |
US20060085492A1 (en) * | 2004-10-14 | 2006-04-20 | Singh Arun K | System and method for modifying process navigation |
FR2882448B1 (fr) * | 2005-01-21 | 2007-05-04 | Meiosys Soc Par Actions Simpli | Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif |
US7478278B2 (en) * | 2005-04-14 | 2009-01-13 | International Business Machines Corporation | Template based parallel checkpointing in a massively parallel computer system |
EP1899902B1 (en) * | 2005-05-30 | 2011-12-28 | Semiconductor Energy Laboratory Co., Ltd. | Semiconductor device and driving method thereof |
US7877350B2 (en) * | 2005-06-27 | 2011-01-25 | Ab Initio Technology Llc | Managing metadata for graph-based computations |
US8572516B1 (en) | 2005-08-24 | 2013-10-29 | Jpmorgan Chase Bank, N.A. | System and method for controlling a screen saver |
US7636946B2 (en) * | 2005-08-31 | 2009-12-22 | Microsoft Corporation | Unwanted file modification and transactions |
US7353332B2 (en) * | 2005-10-11 | 2008-04-01 | Integrated Device Technology, Inc. | Switching circuit implementing variable string matching |
US7499933B1 (en) | 2005-11-12 | 2009-03-03 | Jpmorgan Chase Bank, N.A. | System and method for managing enterprise application configuration |
US8181016B1 (en) | 2005-12-01 | 2012-05-15 | Jpmorgan Chase Bank, N.A. | Applications access re-certification system |
KR100833681B1 (ko) | 2005-12-08 | 2008-05-29 | 한국전자통신연구원 | 커밋 프로토콜을 이용한 병행 프로세스 메모리 관리 시스템및 관리 방법 |
US7574591B2 (en) * | 2006-01-12 | 2009-08-11 | Microsoft Corporation | Capturing and restoring application state after unexpected application shutdown |
US7716461B2 (en) * | 2006-01-12 | 2010-05-11 | Microsoft Corporation | Capturing and restoring application state after unexpected application shutdown |
US7913249B1 (en) | 2006-03-07 | 2011-03-22 | Jpmorgan Chase Bank, N.A. | Software installation checker |
US7895565B1 (en) | 2006-03-15 | 2011-02-22 | Jp Morgan Chase Bank, N.A. | Integrated system and method for validating the functionality and performance of software applications |
US7571347B2 (en) * | 2006-03-20 | 2009-08-04 | Sun Microsystems, Inc. | Method and apparatus for providing fault-tolerance in parallel-processing systems |
US20070276879A1 (en) * | 2006-05-26 | 2007-11-29 | Rothman Michael A | Sparse checkpoint and rollback |
US7610172B2 (en) * | 2006-06-16 | 2009-10-27 | Jpmorgan Chase Bank, N.A. | Method and system for monitoring non-occurring events |
EP1873643A1 (en) * | 2006-06-30 | 2008-01-02 | Alcatel Lucent | Service objects with rollback-recovery |
AU2007286155B2 (en) | 2006-08-10 | 2013-12-12 | Ab Initio Technology Llc. | Distributing services in graph-based computations |
US7539031B2 (en) * | 2006-09-19 | 2009-05-26 | Netlogic Microsystems, Inc. | Inexact pattern searching using bitmap contained in a bitcheck command |
US7529746B2 (en) * | 2006-09-19 | 2009-05-05 | Netlogic Microsystems, Inc. | Search circuit having individually selectable search engines |
US7783654B1 (en) | 2006-09-19 | 2010-08-24 | Netlogic Microsystems, Inc. | Multiple string searching using content addressable memory |
US7539032B2 (en) * | 2006-09-19 | 2009-05-26 | Netlogic Microsystems, Inc. | Regular expression searching of packet contents using dedicated search circuits |
US7644080B2 (en) * | 2006-09-19 | 2010-01-05 | Netlogic Microsystems, Inc. | Method and apparatus for managing multiple data flows in a content search system |
US7624105B2 (en) * | 2006-09-19 | 2009-11-24 | Netlogic Microsystems, Inc. | Search engine having multiple co-processors for performing inexact pattern search operations |
US7917486B1 (en) | 2007-01-18 | 2011-03-29 | Netlogic Microsystems, Inc. | Optimizing search trees by increasing failure size parameter |
WO2008092162A2 (en) | 2007-01-26 | 2008-07-31 | The Trustees Of Columbia University In The City Of New York | Systems, methods, and media for recovering an application from a fault or attack |
US7630982B2 (en) | 2007-02-24 | 2009-12-08 | Trend Micro Incorporated | Fast identification of complex strings in a data stream |
JP5251002B2 (ja) * | 2007-05-25 | 2013-07-31 | 富士通株式会社 | 分散処理プログラム、分散処理方法、分散処理装置、および分散処理システム |
CA2965896C (en) | 2007-07-26 | 2020-01-07 | Ab Initio Technology Llc | Transactional graph-based computation with error handling |
US7643353B1 (en) | 2007-10-25 | 2010-01-05 | Netlogic Microsystems, Inc. | Content addressable memory having programmable interconnect structure |
US8776018B2 (en) | 2008-01-11 | 2014-07-08 | International Business Machines Corporation | System and method for restartable provisioning of software components |
EP2271987A4 (en) * | 2008-05-01 | 2011-04-20 | Hewlett Packard Development Co | STORING CONTROL POINT DATA IN NON-VOLATILE MEMORY |
US20090282058A1 (en) * | 2008-05-12 | 2009-11-12 | Expressor Software | Method and system for developing data integration applications with reusable functional rules that are managed according to their output variables |
US7924589B1 (en) | 2008-06-03 | 2011-04-12 | Netlogic Microsystems, Inc. | Row redundancy for content addressable memory having programmable interconnect structure |
US8291261B2 (en) * | 2008-11-05 | 2012-10-16 | Vulcan Technologies Llc | Lightweight application-level runtime state save-and-restore utility |
JP2010165251A (ja) | 2009-01-16 | 2010-07-29 | Toshiba Corp | 情報処理装置及びプロセッサ並びに情報処理方法 |
KR20150038758A (ko) | 2009-02-13 | 2015-04-08 | 아브 이니티오 테크놀로지 엘엘시 | 태스크 실행 관리 |
US7916510B1 (en) | 2009-08-10 | 2011-03-29 | Netlogic Microsystems, Inc. | Reformulating regular expressions into architecture-dependent bit groups |
US7924590B1 (en) | 2009-08-10 | 2011-04-12 | Netlogic Microsystems, Inc. | Compiling regular expressions for programmable content addressable memory devices |
US8667329B2 (en) * | 2009-09-25 | 2014-03-04 | Ab Initio Technology Llc | Processing transactions in graph-based applications |
US9665620B2 (en) * | 2010-01-15 | 2017-05-30 | Ab Initio Technology Llc | Managing data queries |
CN102263652A (zh) * | 2010-05-31 | 2011-11-30 | 鸿富锦精密工业(深圳)有限公司 | 网络装置及更改其参数设定的方法 |
CN107066241B (zh) | 2010-06-15 | 2021-03-09 | 起元技术有限责任公司 | 用于动态加载基于图的计算的系统和方法 |
US8527488B1 (en) | 2010-07-08 | 2013-09-03 | Netlogic Microsystems, Inc. | Negative regular expression search operations |
US9002946B2 (en) * | 2010-08-25 | 2015-04-07 | Autodesk, Inc. | Dual modeling environment in which commands are executed concurrently and independently on both a light weight version of a proxy module on a client and a precise version of the proxy module on a server |
US8862603B1 (en) | 2010-11-03 | 2014-10-14 | Netlogic Microsystems, Inc. | Minimizing state lists for non-deterministic finite state automatons |
US9116759B2 (en) * | 2011-02-18 | 2015-08-25 | Ab Initio Technology Llc | Restarting data processing systems |
US9021299B2 (en) | 2011-02-18 | 2015-04-28 | Ab Initio Technology Llc | Restarting processes |
US9116955B2 (en) | 2011-05-02 | 2015-08-25 | Ab Initio Technology Llc | Managing data queries |
US9135124B2 (en) * | 2012-04-30 | 2015-09-15 | Hewlett-Packard Development Company, L.P. | Sequence indicator for command communicated to a sequential access storage device |
US9317467B2 (en) | 2012-09-27 | 2016-04-19 | Hewlett Packard Enterprise Development Lp | Session key associated with communication path |
JP6085897B2 (ja) * | 2012-10-09 | 2017-03-01 | ▲ホア▼▲ウェイ▼技術有限公司Huawei Technologies Co.,Ltd. | ウェブアプリケーションにデータベースの変更内容を取得させるための方法及びシステム |
US10108521B2 (en) | 2012-11-16 | 2018-10-23 | Ab Initio Technology Llc | Dynamic component performance monitoring |
US9507682B2 (en) | 2012-11-16 | 2016-11-29 | Ab Initio Technology Llc | Dynamic graph performance monitoring |
US9274926B2 (en) | 2013-01-03 | 2016-03-01 | Ab Initio Technology Llc | Configurable testing of computer programs |
US10002041B1 (en) | 2013-02-01 | 2018-06-19 | Jpmorgan Chase Bank, N.A. | System and method for maintaining the health of a machine |
US9720655B1 (en) | 2013-02-01 | 2017-08-01 | Jpmorgan Chase Bank, N.A. | User interface event orchestration |
US9088459B1 (en) | 2013-02-22 | 2015-07-21 | Jpmorgan Chase Bank, N.A. | Breadth-first resource allocation system and methods |
US9619410B1 (en) | 2013-10-03 | 2017-04-11 | Jpmorgan Chase Bank, N.A. | Systems and methods for packet switching |
WO2015060991A1 (en) | 2013-10-21 | 2015-04-30 | Ab Initio Technology Llc | Checkpointing a collection of data units |
WO2015085152A1 (en) | 2013-12-05 | 2015-06-11 | Ab Initio Technology Llc | Managing interfaces for dataflow graphs composed of sub-graphs |
EP3077904B1 (en) | 2013-12-06 | 2018-04-11 | AB Initio Technology LLC | Source code translation |
US9542259B1 (en) | 2013-12-23 | 2017-01-10 | Jpmorgan Chase Bank, N.A. | Automated incident resolution system and method |
US9868054B1 (en) | 2014-02-10 | 2018-01-16 | Jpmorgan Chase Bank, N.A. | Dynamic game deployment |
US10437819B2 (en) | 2014-11-14 | 2019-10-08 | Ab Initio Technology Llc | Processing queries containing a union-type operation |
US10417281B2 (en) | 2015-02-18 | 2019-09-17 | Ab Initio Technology Llc | Querying a data source on a network |
US10657134B2 (en) | 2015-08-05 | 2020-05-19 | Ab Initio Technology Llc | Selecting queries for execution on a stream of real-time data |
CN108475189B (zh) | 2015-12-21 | 2021-07-09 | 起元技术有限责任公司 | 子图接口生成的方法、系统及计算机可读介质 |
US10601890B2 (en) | 2016-01-14 | 2020-03-24 | Ab Initio Technology Llc | Recoverable stream processing |
JP6665892B2 (ja) * | 2018-07-04 | 2020-03-13 | 富士通株式会社 | 情報処理システム,情報処理装置および制御プログラム |
US11093223B2 (en) | 2019-07-18 | 2021-08-17 | Ab Initio Technology Llc | Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods |
US11847027B2 (en) | 2022-03-15 | 2023-12-19 | Microsoft Technology Licensing, Llc | Automated configuration conflict resolution and lightweight restoration |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4823256A (en) * | 1984-06-22 | 1989-04-18 | American Telephone And Telegraph Company, At&T Bell Laboratories | Reconfigurable dual processor system |
US4665520A (en) * | 1985-02-01 | 1987-05-12 | International Business Machines Corporation | Optimistic recovery in a distributed processing system |
US4703481A (en) * | 1985-08-16 | 1987-10-27 | Hewlett-Packard Company | Method and apparatus for fault recovery within a computing system |
US5121486A (en) * | 1987-11-20 | 1992-06-09 | Hitachi, Ltd | Network control system for dynamically switching a logical connection between an identified terminal device and an indicated processing unit |
US5313584A (en) * | 1991-11-25 | 1994-05-17 | Unisys Corporation | Multiple I/O processor system |
US5335343A (en) * | 1992-07-06 | 1994-08-02 | Digital Equipment Corporation | Distributed transaction processing using two-phase commit protocol with presumed-commit without log force |
US5435003A (en) * | 1993-10-07 | 1995-07-18 | British Telecommunications Public Limited Company | Restoration in communications networks |
US5530802A (en) * | 1994-06-22 | 1996-06-25 | At&T Corp. | Input sequence reordering method for software failure recovery |
US5440726A (en) * | 1994-06-22 | 1995-08-08 | At&T Corp. | Progressive retry method and apparatus having reusable software modules for software failure recovery in multi-process message-passing applications |
US5590277A (en) * | 1994-06-22 | 1996-12-31 | Lucent Technologies Inc. | Progressive retry method and apparatus for software failure recovery in multi-process message-passing applications |
-
1995
- 1995-12-11 US US08/570,724 patent/US5712971A/en not_active Expired - Lifetime
-
1996
- 1996-12-11 EP EP96943730A patent/EP0954779B8/en not_active Expired - Lifetime
- 1996-12-11 DK DK96943730T patent/DK0954779T3/da active
- 1996-12-11 PT PT96943730T patent/PT954779E/pt unknown
- 1996-12-11 JP JP52221797A patent/JP3573463B2/ja not_active Expired - Lifetime
- 1996-12-11 AU AU12888/97A patent/AU1288897A/en not_active Abandoned
- 1996-12-11 DE DE69637836T patent/DE69637836D1/de not_active Expired - Lifetime
- 1996-12-11 WO PCT/US1996/019836 patent/WO1997022052A1/en active Search and Examination
- 1996-12-11 ES ES96943730T patent/ES2320601T3/es not_active Expired - Lifetime
- 1996-12-11 AT AT96943730T patent/ATE423351T1/de active
- 1996-12-11 CA CA002240347A patent/CA2240347C/en not_active Expired - Lifetime
-
2003
- 2003-10-08 JP JP2003349169A patent/JP3675802B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
US5712971A (en) | 1998-01-27 |
AU1288897A (en) | 1997-07-03 |
DE69637836D1 (en) | 2009-04-02 |
PT954779E (pt) | 2009-04-28 |
CA2240347C (en) | 2001-07-10 |
DK0954779T3 (da) | 2009-04-06 |
EP0954779A4 (en) | 2007-05-09 |
JP3675802B2 (ja) | 2005-07-27 |
EP0954779B8 (en) | 2009-04-22 |
JP2002505768A (ja) | 2002-02-19 |
JP2004094963A (ja) | 2004-03-25 |
ATE423351T1 (de) | 2009-03-15 |
EP0954779A1 (en) | 1999-11-10 |
EP0954779B1 (en) | 2009-02-18 |
WO1997022052A1 (en) | 1997-06-19 |
CA2240347A1 (en) | 1997-06-19 |
JP3573463B2 (ja) | 2004-10-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2320601T3 (es) | Metodo para reconstruir el estado de un calculo. | |
US6766471B2 (en) | User-level checkpoint and restart for groups of processes | |
EP1495414B1 (en) | Transparent consistent active replication of multithreaded application programs | |
EP0772136B1 (en) | Method of commitment in a distributed database transaction | |
US7178062B1 (en) | Methods and apparatus for executing code while avoiding interference | |
US5276876A (en) | Registration of resources for commit procedures | |
US5261089A (en) | Optimization of commit procedures by utilizing a two-phase commit procedure only when necessary | |
JPS63225851A (ja) | 複数データ処理装置間フアイル共有方式 | |
US6092084A (en) | One system of a multisystem environment taking over log entries owned by another system | |
Sharma et al. | Grove: a separation-logic library for verifying distributed systems | |
US6076095A (en) | Method of one system of a multisystem environment taking over log entries owned by another system | |
Gray | Agent Tcl: Alpha Release 1.1 | |
Salzberg et al. | DSDT: Durable scripts containing database transactions | |
Campbell et al. | Practical fault tolerant software for asynchronous systems | |
Ravindran et al. | Failure transparency in remote procedure calls | |
Weggerle et al. | Transaction based device driver developement | |
Reiss et al. | Automated support for recovery | |
Nett et al. | Implementing fault-tolerance in a distributed system architecture | |
Mellor-Crummey et al. | Elmwood-An Object-Oriented Multiprocessor Operating System | |
Krawczuk | Distributed debugging based on deterministic reexecution: methodology and design of a working prototype | |
Kobus et al. | Paxos STM–User Guide | |
Gibson | Computation management in a single address space system | |
Drew | Fail-safety techniques and their extensions to concurrent systems | |
TERA COMPUTER CO SEATTLE WA | User Process Checkpoint/Restart. Revision 1.1. | |
Carpenter | Wull ye come in eärly spring/John Alden Carpenter; poem by William Barnes. |