ES2367886T3 - Gestión de recursos. - Google Patents

Gestión de recursos. Download PDF

Info

Publication number
ES2367886T3
ES2367886T3 ES01304909T ES01304909T ES2367886T3 ES 2367886 T3 ES2367886 T3 ES 2367886T3 ES 01304909 T ES01304909 T ES 01304909T ES 01304909 T ES01304909 T ES 01304909T ES 2367886 T3 ES2367886 T3 ES 2367886T3
Authority
ES
Spain
Prior art keywords
application
resource
prioritized
identity
request
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
Application number
ES01304909T
Other languages
English (en)
Inventor
Morteza Kalhour
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Inc
Original Assignee
Nokia Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nokia Inc filed Critical Nokia Inc
Application granted granted Critical
Publication of ES2367886T3 publication Critical patent/ES2367886T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/52—Indexing scheme relating to G06F9/52
    • G06F2209/522—Manager

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Traffic Control Systems (AREA)

Abstract

Procedimiento, que comprende: recibir, (S1), en un recurso (29), una solicitud de asignacion de recursos, siendo el recurso compartido entre una primera aplicacion de software a la que el recurso (29) esta actualmente asignado y una segunda aplicacion de software que solicita el acceso al recurso, incluyendo la solicitud del recurso una identidad para la segunda aplicacion; comparar, (S5), en el recurso (29), la identidad de la segunda aplicacion con una identidad de una aplicacion de software predeterminada para determinar si la segunda aplicacion es la aplicacion priorizada predeterminada; en el caso de que la segunda aplicacion sea la aplicacion priorizada predeterminada, el recurso que determina (S8) si tiene la autoridad para asignarse a si mismo a la segunda aplicacion sobre la base de la informacion (NI), que indica como la primera aplicacion utiliza el recurso; y en el caso de que el recurso tenga la autoridad para asignarse a si mismo a la segunda aplicacion, la asignacion del recurso (S9) a si mismo a la segunda aplicacion.

Description

La presente invención se refiere al campo de la gestión de recursos, particularmente pero no exclusivamente, a la resolución de conflictos entre dos o más aplicaciones de software que solicitan el acceso al mismo recurso.
Un ordenador convencional tiene una serie de recursos tales como la pantalla, sistema de sonido, dispositivos de memoria, unidad de disco duro, etc., lo que puede ser utilizado por cualquiera de las aplicaciones que se ejecutan en el sistema. Sin embargo, los recursos pueden servir sólo a un número limitado de aplicaciones al mismo tiempo, por lo que en un entorno de múltiples aplicaciones, existe una necesidad de un sistema de gestión de recursos que es más flexible, manejable y al mismo tiempo más fácil de usar que aquel de un ordenador convencional.
El documento EP 0543560 A2 divulga un procedimiento para permitir el acceso a una pluralidad de procesadores a un recurso compartido. El procedimiento incluye la determinación de las prioridades de un procesador que solicita el recurso compartido y un procesador al que actualmente el recurso compartido se encuentra concedido.
El documento US 6009426 divulga un procedimiento de gestión de una memoria compartida entre los procesos de la competencia. El procedimiento incluye la asignación de "espera", un "bloqueo de lectura" o "bloqueo de escritura" a una variable.
El documento EP 0783152 A2 divulga un procedimiento y aparato para la gestión de cómo los subprocesos de un programa de ordenador de múltiples procesos comparten un recurso. Se da prioridad a uno de los subprocesos del programa sobre otros subprocesos y los otros subprocesos tienen que indicar al subproceso de prioridad cuando requieren el uso de los recursos. Cuando el subproceso de prioridad se realiza mediante el recurso puede liberar el recurso a uno de los otros subprocesos. Después que uno de los otros subprocesos se realiza mediante el recurso, éste se libera de nuevo al subproceso de prioridad siguiendo una solicitud automática desde el subproceso de prioridad.
De acuerdo con la presente invención, se proporciona un procedimiento que comprende: recibir, en un recurso, una solicitud de asignación de recurso, siendo el recurso compartido entre una primera solicitud a la que el recurso es actualmente asignado y una segunda aplicación que solicita el acceso al recurso, incluyendo la solicitud de recurso una identidad para la segunda aplicación; comparar, en el recurso, la identidad de la segunda aplicación con una identidad para una aplicación de prioridad predeterminada para determinar si la segunda aplicación es la aplicación de prioridad predeterminada, en el caso de que el segunda aplicación es la aplicación de prioridad predeterminada, el recurso determina si tiene la autoridad para asignarse a sí mismo a la segunda aplicación sobre basado en la información que indica la forma en que la primera aplicación utiliza el recurso, y en caso de que el recurso tenga la autoridad para asignarse a sí mismo a la segunda aplicación, asignándose el recurso a sí mismo a la segunda aplicación.
Al determinar si la aplicación que solicita el recurso es una aplicación de prioridad predeterminada, una aplicación que se encuentra actualmente en el foco, por ejemplo, la aplicación que actualmente se encuentra priorizada por el usuario, puede ser considerada para la asignación de recursos, mientras que otras aplicaciones son rechazadas.
Al permitir que el recurso se asigne a sí mismo a la segunda aplicación, donde no hay barreras para hacerlo, resulta un procedimiento eficiente de asignación del recurso sin necesidad de implicar componentes de mayor nivel en el proceso de toma de decisiones. Sin embargo, en el caso de que el recurso no tenga la autoridad para permitir la asignación, el procedimiento puede comprender solicitar una decisión sobre si se debe asignar el recurso. La decisión puede implicar componentes de un nivel más alto que tienen una visión general de los recursos del sistema. La decisión puede depender de las prioridades predeterminadas asignadas a la primera y segunda aplicación, o puede depender de la entrada del usuario.
El procedimiento también puede comprender la selección de una aplicación que debe ser priorizada en la asignación de recursos y comunicación de información para identificar la aplicación priorizada al recurso.
De acuerdo con la invención, se proporciona también un programa para la ejecución mediante un procesador para la aplicación del procedimiento.
De acuerdo con la presente invención, se proporciona también un aparato que comprende: un recurso para compartir entre aplicaciones; y medios para asignar el recurso compartido entre una pluralidad de aplicaciones que solicitan acceso a los recursos, en el que, en la determinación de la asignación de los recursos entre una primera aplicación a la que actualmente el recurso es asignado y una segunda aplicación que solicita el acceso al recurso, el recurso está configurado para recibir una identidad para la segunda aplicación, para comparar la identidad de la segunda aplicación con una identidad para una aplicación de prioridad predeterminada para determinar si la segunda aplicación es la aplicación de prioridad predeterminada, en caso de que la segunda aplicación es la aplicación predeterminada prioridad, para determinar si el recurso tiene la autoridad para asignarse a sí mismo a la segunda aplicación sobre la base de la información que indica cómo la primera aplicación utiliza el recurso y, en caso de que el recurso tenga la autoridad para asignarse a sí mismo la segunda aplicación, se asignará a sí mismo la segunda aplicación.
Las realizaciones de la invención se divulgan a modo de ejemplo con referencia a los dibujos adjuntos, en los que:
La figura 1 es un diagrama esquemático de un sistema informático que incluye una representación del software de acuerdo con la invención en forma de un modelo de capa;
La figura 2 es un diagrama esquemático que muestra los detalles del sistema informático en la figura 1;
La figura 3 es un diagrama esquemático que ilustra los componentes existentes en cada capa del modelo de capa descrito en relación a la figura 1;
La figura 4 es un diagrama esquemático que ilustra la distribución de información relativa a la aplicación enfocada en el sistema de acuerdo con la invención;
La figura 5 es un diagrama de flujo esquemático que ilustra un procedimiento de gestión de los recursos de acuerdo con la invención;
La figura 6 es un diagrama esquemático que ilustra una solicitud de asignación de una aplicación de enfoque en el modo de usuario;
La figura 7 es un diagrama esquemático que ilustra una solicitud de asignación de una aplicación que no se enfoca en el modo de usuario;
La figura 8 es un diagrama esquemático que ilustra una solicitud de asignación de una aplicación que no se enfoca en el modo de propietario;
La figura 9 es un diagrama esquemático que ilustra una solicitud de asignación de una aplicación de enfoque en el modo de propietario en que el recurso tiene la autoridad para llevar a cabo la asignación; y
La figura 10 es un diagrama esquemático que ilustra una solicitud de asignación de una aplicación que se enfoca en el modo de propietario en que el recurso no tiene la autoridad para llevar a cabo la asignación.
La figura 1 es un diagrama esquemático de un ordenador 1 que incluye un software de ordenador 2 y hardware de ordenador 3. El software 2 incluye software del sistema operativo 4 y software de gestión de recursos 5, representados en términos de un modelo de capa 6, 7, 8, que comprende una capa de aplicación (la más alta) 6, una capa de recurso (media) 7 y una capa de controlador de dispositivo (la más baja) 8.
La figura 2 muestra con más detalle los dispositivos de hardware mostrados en la figura 1. El ordenador 1 comprende una unidad de procesamiento central (CPU) 10 para la ejecución de programas de ordenador y gestionar y controlar el funcionamiento del ordenador. La CPU 10 está conectada a una serie de dispositivos a través de un bus 11, incluyendo los dispositivos un dispositivo de escritura/lectura 12, por ejemplo una disquetera para leer y escribir datos, programas informáticos y de un medio de almacenamiento extraíble como un disquete 13, un dispositivo de almacenamiento 14, por ejemplo, una unidad de disco duro para el almacenamiento del sistema y del software de aplicación y dispositivos de memoria incluyendo ROM 15 y RAM 16. El ordenador incluye, además, dispositivos de entrada/salida para el usuario, como un ratón 17, un teclado 18 y una pantalla 19. Se entenderá que el hardware de ordenador que se ha descrito anteriormente es totalmente convencional y que otras variaciones son posibles, por ejemplo, el ordenador puede estar provisto de un dispositivo de comunicaciones tal como un módem y otras formas de almacenamiento como un CD-ROM y/o unidad de DVD. El ordenador ejecuta un software del sistema operativo 4 como Linux con un entorno de escritorio como Gnome o KDE.
En referencia a la figura 3, los componentes de software existentes en cada una de las capas 6, 7, 8 que se muestran en la figura 1 se describirán a continuación en detalle, comenzando con la capa más baja 8.
La capa más baja 8 comprende una serie de módulos de software de controlador de dispositivo convencionales, por ejemplo, un controlador de pantalla 21, un controlador de disco duro 22 y un controlador “hardware n” generalizado 23. Al igual que en un sistema informático convencional, cada controlador de dispositivo controla un dispositivo de hardware asociado, por ejemplo una tarjeta de video 24, un disco duro 25, así como un dispositivo “hardware n” generalizado 26.
La capa de recurso (media) 7 comprende una serie de componentes de software cada uno definiendo un recurso, incluyendo un recurso de pantalla 27, recursos de disco duro 28 y un recurso generalizado “recurso n” 29, bajo el control de un administrador del sistema 30. Cada recurso 27, 28, 29 implementa estrategias de gestión de recursos de acuerdo con la invención mediante el control de los correspondientes controladores de dispositivos convencionales 21, 22, 23 y utilizando su funcionalidad para controlar los dispositivos de hardware asociados 24, 25, 26. Un experto en la técnica entenderá que los recursos de la capa media se proporcionan para permitir el uso de controladores de dispositivos estándar. En el caso de que los controladores de dispositivo estándar no sean necesarios, la funcionalidad de las capas media y baja 7, 8 se pueden combinar, de manera que un recurso entonces proporciona la funcionalidad de un controlador de dispositivo junto con la funcionalidad de gestión de recursos de acuerdo con la invención. Del mismo modo, se entenderá que un solo recurso puede combinar la funcionalidad de una serie de controladores de dispositivos.
Un administrador del sistema (SM) 30 es un componente de software de la capa media que se encarga de crear todos los recursos de capa media 27, 28, 29, y del seguimiento de su funcionalidad, y también lleva a cabo funciones específicas de gestión de los recursos que se detallan a continuación. En el inicio del sistema, el administrador del sistema 30 pasa a través de una lista de recursos de capa media pre-registrados y los crea. Después de su creación, estos recursos nos ofrecen su funcionalidad a las aplicaciones en la capa de aplicación. Los recursos de la capa media 27, 28, 29 actúan de manera eficaz como servidores para las aplicaciones clientes en la capa de aplicación.
La capa de aplicación 6 incluye una serie de aplicaciones que tienen identificadores de aplicación aid_1, aid_2 ..., aid_n. Un identificador de la aplicación identifica de forma única una aplicación y se utiliza durante el procedimiento de asignación de recursos. Diferentes procesos dentro de una aplicación usa la misma identificación de aplicación para la asignación de recursos. La totalidad de las aplicaciones define un entorno de usuario 31, por ejemplo, el entorno de usuario Gnome o KDE, bajo el control de un módulo de controlador de entorno de usuario 32 que tiene la responsabilidad general por el entorno de usuario particular 31 y es plenamente consciente de todas las opciones de configuración y las preferencias establecidas por el usuario, así como conocer la identidad de las aplicaciones actualmente activas. Un administrador de aplicaciones 33 coordina el uso de la capa media 7 e incluye recursos API e información de configuración que le permiten poner en marcha diferentes entornos de usuario o cambiar entre los entornos de usuario.
Con referencia a la figura 4, el controlador de entorno de usuario 32 comunica la identidad de una aplicación referida en adelante como la aplicación enfocada, o favorecida, al administrador de la aplicación 33. La aplicación enfocada es la aplicación que se ve favorecida cuando los recursos son asignados y utilizados. Por ejemplo, la aplicación enfocada es la aplicación actualmente activa o una aplicación a la que el usuario da prioridad en un momento determinado, que suele ser, pero no necesariamente, la aplicación con la que el usuario está interactuando en ese momento. Una aplicación focalizada tiene la máxima prioridad y no pierde sus recursos a cualquier otra aplicación, aunque el enfoque cambia de forma dinámica entre las aplicaciones cuando el usuario realiza diferentes tareas en el entorno de usuario.
El administrador de aplicaciones 33 transmite la identidad de la aplicación enfocada al administrador del sistema 30. A su vez, el administrador del sistema 30 comunica el identificador de la aplicación enfocada para cada uno de los recursos 27, 28, 29. El administrador del sistema 30 también es responsable de informar a los recursos cuando el foco cambia de una aplicación a otra.
Procedimiento de asignación
La figura 5 explica el proceso de gestión de los recursos de acuerdo con la invención, comenzando de la posición de que un determinado recurso es propiedad de una aplicación con el identificador de la aplicación aid_1, con referencia a cada una de las figuras 6 a 10, que ilustran la posición cuando otra aplicación requiere la asignación de los recursos, de acuerdo con distintos escenarios.
En términos generales, cuando una aplicación desea solicitar la asignación de un recurso 29, que es actualmente propiedad de otra aplicación, emite una llamada de función con tres parámetros:
Asignar (aplicación id, indicador de que no se puede interrumpir, indicador propiedad)
La identificación de la aplicación identifica la aplicación que hace la solicitud para el recurso, en el caso general, aid_x. El indicador de que no se puede interrumpir (NI) indica cómo la aplicación intenta utilizar los recursos si se asigna el recurso. Si el indicador se establece en “VERDADERO”, la propiedad del recurso no debe ser quitada de la aplicación que actualmente la posee sin informar al administrador de aplicaciones 33. Si el indicador se establece en “FALSO”, el recurso en sí mismo tiene la autoridad para aprobar la propiedad de sí mismo para otras aplicaciones, en ciertas circunstancias, que se describirán en detalle a continuación. Si el indicador NI se divulga el estado como “no importa”, esto significa que el indicador puede establecerse como VERDADERO o FALSO, pero su estado es irrelevante para el procedimiento en cuestión.
El indicador de propiedad indica cómo la aplicación solicitante tiene la intención de gestionar los recursos. Si el indicador se establece en VERDADERO, la aplicación solicitante tiene la intención de controlar los recursos y por lo tanto, requiere el acceso a las funciones que pueden cambiar el estado interno de los recursos. Si el indicador se establece en FALSO, la aplicación solicitante desea ser considerada como sólo usuario, en cuyo modo sólo se le permite llamar a funciones que no están destinadas a controlar los recursos, y por lo tanto no puede modificar el estado interno del recurso.
Un recurso 29 se divulga con referencia a las figuras 6 a 10 que tienen un estado inicial 29A antes de la petición de asignación y un estado final 29B después de la petición de asignación. Cada recurso 29 se asocia con una serie de campos:
-Un indicador que no se puede interrumpir (NI) indica cómo la aplicación actualmente propietaria utiliza el recurso. Cuando el recurso ha cambiado de manos como resultado de una petición de asignación (...) tal como se describió anteriormente, el indicador NI se establece en el valor especificado en esa solicitud.
-Un registro de propietario almacena el identificador de la aplicación del actual propietario del recurso.
-Un registro de los usuarios almacena el identificador de la aplicación de todos los usuarios del recurso. Como se describió anteriormente, el usuario tiene acceso limitado al recurso.
-Un registro de Usuarios_Pasivos almacena el identificador de la aplicación de todos los propietarios pasivos del recurso. El propietario pasivo tiene el mismo nivel de accesibilidad al recurso como un usuario. La diferencia es que si la presente aplicación libera el recurso y no hay ninguna otra aplicación enfocada que solicite su propiedad, el recurso va a través de su pila de propietarios pasivos y les pregunta si desean recuperar el control del recurso.
-Un registro de enfoque registra el identificador de la aplicación de la aplicación enfocada, se comunica con el recurso a través del administrador del sistema 30, como se ha descrito anteriormente con referencia a la figura 4.
La figura 6 divulga la situación en la que la aplicación enfocada solicita el recurso en el modo de usuario.
El estado inicial 29A del recurso 29 es que el indicador que no se puede interrumpir (NI) puede ser configurado como VERDADERO o FALSO y el registro de propietario registra que el recurso 29 es actualmente propiedad de la aplicación aid_1. La identidad de la aplicación enfocada es aid_2.
El recurso 29A registra, además, que no hay propietarios pasivos y ningún usuario se registra para el recurso.
Con referencia a las figuras 5 y 6, una aplicación aid_x, donde x = 2, que es la aplicación enfocada actual, solicita el recurso 29, que es actualmente propiedad de la aplicación aid_1, por lo que la petición de asignación está en la forma:
Asignar (aid_2, NI = No preocuparse, Propietario = Falso) (etapa s1).
El recurso 29 mira primero el indicador de propiedad en la petición de asignación (etapa s2). El hecho de que el indicador de propiedad esté establecido en FALSO indica que la aplicación aid_2 sólo está solicitando la condición de usuario del recurso. Como resultado, aid_2 se registra como usuario en el recurso 29 (etapa s3), como se muestra en el estado final 29B del recurso en la figura 6 y este hecho se notifica a la aplicación enfocada aid_2 (etapa S4).
Es evidente a partir de la descripción anterior que, en el caso de una solicitud de registrarse como un usuario, el estado de una aplicación como una aplicación enfocada u otro es irrelevante, ya que el recurso 29 no pone en duda la identidad de la aplicación solicitada aid_2. Por lo tanto, una aplicación sin estado enfocado que solicita estado de usuario también es concedida a esta solicitud en las mismas circunstancias, como se ilustra en la figura 7 para una aplicación no enfocada aid_3.
La figura 8 muestra la situación en la que la aplicación que efectúa la petición de asignación no es una aplicación enfocada, pero la solicitud se realiza con el indicador de propiedad establecido en:
Asignar (aid_3, NI = No preocuparse, Propietario = Verdadero) (etapa s1)
En este caso, en referencia a la figura 5, el recurso 29 comprueba el indicador de propiedad (etapa s2) y determina que la solicitud es una solicitud de propiedad del recurso. El recurso por lo tanto, comprueba el estado de enfoque de la aplicación mediante la comparación de la identidad de la aplicación de solicitud notificada en la petición de asignación con la identidad de la aplicación enfocada almacenada mediante el recurso 29 (etapa S5). En este caso, la aplicación que hace la solicitud de asignación, aid_3, no es la aplicación enfocada, que el estado inicial 29A del recurso muestra que es aid_2. Por lo tanto, la solicitud de asignación es rechazada (etapa S6) y la solicitud de aplicación aid_3 es notificada del rechazo (etapa S7). La figura 8 muestra que no hay ningún cambio entre los estados inicial 29A y final 29B del recurso 29 en este caso.
La figura 9 ilustra el caso en que la aplicación enfocada hace la solicitud de asignación de recursos en el modo de propietario:
Asignar (aid_2, NI = No preocuparse, Propietario = Verdadero) (etapa s1)
Al igual que antes, una comprobación del indicador de propiedad del recurso (etapa s2) revela que este se establece en VERDADERO, por lo que el recurso procede a comprobar el estado de enfoque de la aplicación (etapa S5). Esto indica que la aplicación solicitante es la aplicación enfocada, por lo que el recurso 29 procede a verificar el estado de su indicador de no interrupción (etapa s8). Dado que el indicador de no interrupción en el recurso 29 se establece en FALSO, la aplicación aid_1 no se opone a la adquisición del recurso por la aplicación de enfoque. El recurso 29 por lo tanto, tiene la autoridad para asignarse a sí mismo la aplicación solicitante aid_2 sin hacer referencia al administrador de aplicación 33. El recurso es por lo tanto asignado a la aplicación aid_2 (etapa S9). El estado final 29B del recurso refleja ahora que su dueño es la aplicación aid_2. El recurso notifica a la aplicación aid_1 de la transferencia de propiedad (etapa S10), así como la notificación a la aplicación aid_2 de que la propiedad se ha transferido (etapa S11). El recurso también establece la solicitud aid_1 como una propietaria pasiva (etapa S12).
La figura 10 ilustra el caso de que tanto la aplicación enfocada solicitante y la aplicación propietaria requieren el recurso en modo propietario, es decir, la solicitud de asignación está en la forma:
Asignar (aid_2, NI = No preocuparse, Propietario = Verdadero) (etapa s1)
y el indicador no interrupción (NI) en el recurso 29A se establece en VERDADERO. El estado de este indicador indica que las operaciones que realiza la aplicación no enfocada actualmente propietaria son críticas, es decir, que no se puede interrumpir, por lo que no debe permitirse al recurso que se asigne a sí mismo a la aplicación enfocada, sin referirse a una autoridad de nivel superior.
En referencia a la figura 5, en este caso, el procedimiento realizado por el recurso 29 es el mismo que se realiza para el caso anterior, hasta el punto en que el indicador NI es interrogado (etapa s8). El recurso 29 determina que su indicador NI está establecido en VERDADERO, por lo tanto que la actual aplicación propietaria aid_1 no desea renunciar a la propiedad del recurso, incluso a una aplicación enfocada. Como resultado de ello, el recurso determina que es incapaz de resolver las demandas conflictivas sobre sí mismo, sin referencia al administrador de la aplicación 33.
El recurso 29 por lo tanto, envía una solicitud de resolución de conflictos para el administrador del sistema 30 (etapa S13) con los identificadores de aplicación, y aid_1 aid_2, de las dos aplicaciones en conflicto. El administrador del sistema 30 remite la solicitud de resolución de conflictos al administrador de aplicaciones 31 (etapa S14). El administrador de aplicaciones 33 resuelve entonces el conflicto (etapa S15).
La resolución de conflictos se realiza en una de varias maneras. Por ejemplo, el administrador de aplicaciones registra una devolución de llamada para la resolución de conflictos con el entorno de usuario del controlador 32, que permite al controlador de entorno de usuario 32 notificar al administrador de aplicaciones 33 cómo el conflicto debería ser resuelto (etapa S16). Le corresponde entonces al controlador de entorno de usuario 32 decidir cómo resolver el conflicto. Una posibilidad es utilizar una lista de prioridad codificada dura entre las aplicaciones, otra dejar que el usuario final decida, por ejemplo por medio de un cuadro de diálogo. Por otra parte, el controlador de entorno de usuario 32 proporciona al administrador de aplicaciones 33 con una tabla de prioridades, por ejemplo una matriz de nombres de archivos de aplicación ejecutables (etapa S17), y permite que el administrador de aplicaciones 33 resuelva un conflicto. En caso de que no se proporcione una devolución de llamada, ni una lista de prioridades al administrador de la aplicación 33, el administrador de aplicaciones 33 resuelve el conflicto de acuerdo con su propio conjunto de reglas, por ejemplo, mediante la negación de la solicitud de recursos más reciente sobre las bases de que la operación en curso es más importante (etapa S18).
Cuando el conflicto ha sido resuelto por el administrador de la aplicación 33, se informa al administrador del sistema 30 de los resultados (etapa S19). El administrador del sistema 30, a su vez informa al recurso 29 de los resultados (etapa S20), por ejemplo, si la aplicación aid_1 o la aplicación aid_2 deben ser favorecidas. El recurso 29 se asigna entonces adecuadamente. Por ejemplo, al referirse a la figura 10, si la aplicación aid_1 es favorecida, entonces el estado final del recurso 29B permanece inalterable desde su estado inicial 29A.
Si, por otro lado, la aplicación aid_2 es favorecida, entonces la asignación de recursos para la aplicación aid_2 procede de la misma manera como si el indicador de no interrupción se ha establecido en FALSO (etapas S9 a S12), tal como se refleja en el estado final del recurso 29C mostrado en la figura 10. El estado No preocuparse que se muestra para el indicador NI en el estado final del recurso 29C indica que esta opción tiene el valor del indicador NI en la solicitud de asignación original.
Aunque se ha descrito una arquitectura particular para el envío de información entre el recurso y el administrador de aplicaciones a través de un administrador del sistema, será evidente que otras arquitecturas también son posibles. Por ejemplo, la información de los conflictos se puede enviar directamente desde un recurso al administrador de aplicaciones y viceversa, sin pasar por el administrador del sistema.
Para evitar la interacción innecesaria con el usuario cuando dos aplicaciones compiten por varios recursos, una elección hecha entre las aplicaciones durante la primera resolución de conflicto se almacena en caché y se comprueba durante el siguiente conflicto de recursos. El caché se borra cuando el enfoque está encendido, ya que a continuación
5 se inicia un cambio en las prioridades de aplicación. Por otra parte, el caché se limpia periódicamente.
A fin de mantener la estabilidad del sistema, cada recurso 27, 28, 29 mantiene un registro de las solicitudes presentadas por las aplicaciones, junto con el estado de la petición. Si un error fatal causa que cualquiera de los recursos falle, el administrador del sistema 30 recrea esos recursos, haciendo todo el sistema más estable en materia de fallos de recursos individuales. Cuando un recurso se reinicia después de una terminación inesperada, comprueba
10 su registro para las solicitudes pendientes. Si se puede completar la solicitud, lo hace, de lo contrario informa a la aplicación solicitante para darle la oportunidad de recuperarse de un evento imprevisto.
Aunque la invención ha sido descrita con referencia principalmente al software que se ejecuta en un ordenador convencional, es aplicable a cualquier dispositivo de tipo ordenador o microprocesador que tiene una serie de recursos que deben ser supervisados y gestionados por el sistema. En términos generales, un recurso es cualquier componente
15 de software que tiene una limitación de cómo otros componentes pueden acceder al mismo y que sólo puede servir a un número limitado de clientes al mismo tiempo. Sin embargo, un recurso puede ser cualquier dispositivo o componente de hardware en el que se pueden aplicar las estrategias de manejo de recursos descritos anteriormente.

Claims (23)

  1. REIVINDICACIONES
    1. Procedimiento, que comprende:
    recibir, (S1), en un recurso (29), una solicitud de asignación de recursos, siendo el recurso compartido entre una primera aplicación de software a la que el recurso (29) está actualmente asignado y una segunda aplicación de software que solicita el acceso al recurso, incluyendo la solicitud del recurso una identidad para la segunda aplicación;
    comparar, (S5), en el recurso (29), la identidad de la segunda aplicación con una identidad de una aplicación de software predeterminada para determinar si la segunda aplicación es la aplicación priorizada predeterminada;
    en el caso de que la segunda aplicación sea la aplicación priorizada predeterminada, el recurso que determina (S8) si tiene la autoridad para asignarse a sí mismo a la segunda aplicación sobre la base de la información (NI), que indica cómo la primera aplicación utiliza el recurso; y
    en el caso de que el recurso tenga la autoridad para asignarse a sí mismo a la segunda aplicación, la asignación del recurso (S9) a sí mismo a la segunda aplicación.
  2. 2.
    Procedimiento según la reivindicación 1, en el que la solicitud de recursos incluye además información de cómo la segunda aplicación tiene la intención de utilizar el recurso e información sobre la forma en que la segunda aplicación tiene la intención de gestionar el recurso.
  3. 3.
    Procedimiento según la reivindicación 1 ó 2 que comprende:
    en el caso de que el recurso no tenga la autoridad para asignarse a sí mismo a la segunda aplicación, el recurso solicita una decisión en cuanto a cómo asignarse a sí mismo.
  4. 4.
    Procedimiento según la reivindicación 3, en el que la decisión depende de la entrada de un usuario de la primera y segunda aplicación.
  5. 5.
    Procedimiento según la reivindicación 3, en el que la decisión depende de prioridades predeterminadas asignadas a la primera y segunda aplicación.
  6. 6.
    Procedimiento según la reivindicación 3, en el que la decisión comprende denegar la asignación a la segunda aplicación.
  7. 7.
    Procedimiento según una cualquiera de las reivindicaciones anteriores, en el que la identidad de la aplicación priorizada se almacena en el recurso.
  8. 8.
    Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende, en caso de que la segunda aplicación solicite el uso del recurso sin solicitar su asignación, registrar la segunda aplicación como un usuario con independencia de si se trata de la aplicación priorizada.
  9. 9.
    Procedimiento según una cualquiera de las reivindicaciones anteriores, que comprende seleccionar una aplicación que debe ser priorizada durante la asignación de recursos y comunicar información para identificar la aplicación priorizada al recurso.
  10. 10.
    Procedimiento según la reivindicación 9, que comprende además la actualización del recurso con la información relativa a cambios en la aplicación priorizada.
  11. 11.
    Procedimiento según la reivindicación 9 ó 10, que incluye la determinación de la aplicación priorizada como la aplicación que se prioriza en un momento dado.
  12. 12.
    Procedimiento según la reivindicación 11, en el que la aplicación priorizada comprende la aplicación con la que el usuario está interactuando en el momento dado.
  13. 13.
    Aparato, que comprende:
    un recurso (29) para compartir entre aplicaciones de software; y
    medios para la asignación del recurso compartido entre una pluralidad de aplicaciones de software que solicitan el acceso al recurso,
    en el que, en la determinación de la asignación del recurso (29) entre una primera aplicación de software a la que el recurso está asignado actualmente y una segunda aplicación de software que solicita el acceso al recurso, el recurso está configurado para recibir una identidad para la segunda aplicación, comparar la identidad de la segunda aplicación a la identidad de una aplicación de software priorizada predeterminada para determinar si la segunda aplicación es la aplicación priorizada predeterminada, en caso de que la segunda aplicación sea la aplicación priorizada predeterminada, determinar si el recurso tiene la autoridad para asignarse a sí mismo a la segunda aplicación sobre la base de información sobre la forma cómo la primera aplicación utiliza el recurso y, en caso de que el recurso tenga la autoridad para asignarse a sí mismo a la segunda aplicación, asignarse a sí mismo a la segunda aplicación.
  14. 14.
    Aparato según la reivindicación 13, en el que el recurso está configurado además para recibir información sobre la forma en que la segunda aplicación tiene la intención de utilizar el recurso e información sobre la forma en que la segunda aplicación tiene la intención de gestionar el recurso.
  15. 15.
    Aparato según la reivindicación 13 ó 14, en el que el recurso está configurado para solicitar una decisión en cuanto a cómo asignarse a sí mismo en el caso de que el recurso no tenga la autoridad para asignarse a sí mismo a la segunda aplicación.
  16. 16.
    Aparato según la reivindicación 15, en el que la decisión depende de la entrada de un usuario de la primera y segunda aplicación.
  17. 17.
    Aparato según la reivindicación 15 ó 16, en el que la decisión depende de las prioridades previamente asignadas a la primera y segunda aplicación.
  18. 18.
    Aparato según la reivindicación 15, 16 ó 17, en el que la decisión comprende denegar la asignación a la segunda aplicación.
  19. 19.
    Aparato según una cualquiera de las reivindicaciones 13 a 18, en el que la identidad de la aplicación priorizada se almacena en el recurso.
  20. 20.
    Aparato según una cualquiera de las reivindicaciones 13 a 19, que también comprende un controlador para la determinación de la aplicación que debe ser priorizada en la asignación de recursos.
  21. 21.
    Aparato según una cualquiera de las reivindicaciones 13 a 20, que comprende además un administrador de aplicaciones (33) para resolver un conflicto en una solicitud del recurso entre la primera y segunda aplicación.
  22. 22.
    Aparato según la reivindicación 21, en el que el conflicto surge cuando tanto la primera como la segunda aplicación requieren la propiedad del recurso (29).
  23. 23.
    Producto de programa para ordenador para la ejecución mediante un procesador para implementar de las etapas según cualquiera de las reivindicaciones 1 a 12.
ES01304909T 2000-06-30 2001-06-05 Gestión de recursos. Expired - Lifetime ES2367886T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0016152A GB2364143A (en) 2000-06-30 2000-06-30 Resource allocation
GB0016152 2000-06-30

Publications (1)

Publication Number Publication Date
ES2367886T3 true ES2367886T3 (es) 2011-11-10

Family

ID=9894813

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01304909T Expired - Lifetime ES2367886T3 (es) 2000-06-30 2001-06-05 Gestión de recursos.

Country Status (5)

Country Link
US (1) US7150020B2 (es)
EP (1) EP1187019B1 (es)
AT (1) ATE520077T1 (es)
ES (1) ES2367886T3 (es)
GB (1) GB2364143A (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004068277A2 (en) 2002-01-18 2004-08-12 Idetic, Inc. Method and system of performing transactions using shared resources and different applications
EP1543419A2 (en) 2002-09-20 2005-06-22 Koninklijke Philips Electronics N.V. Method and system for allocating shared resources between applications
DE10260128B4 (de) * 2002-12-19 2004-12-02 Db Systems Gmbh Ressourcenverwaltung für IP-basierte Netze mit zentraler Eskalations-Instanz
JP3822577B2 (ja) 2003-05-22 2006-09-20 株式会社エヌ・ティ・ティ・ドコモ コンピュータ及びプログラム
JP2005005909A (ja) * 2003-06-10 2005-01-06 Sony Ericsson Mobilecommunications Japan Inc 競合管理プログラム，競合管理プログラムが記憶された記憶媒体，競合管理方法及び電子機器
GB2408361B (en) * 2003-11-21 2007-07-25 Symbian Ltd Allocation of resources in a computing device
GB2412754B (en) * 2004-03-30 2007-07-11 Hewlett Packard Development Co Provision of resource allocation information
US7814491B1 (en) * 2004-04-14 2010-10-12 Oracle America, Inc. Method and apparatus for managing system resources using a container model
US7617498B1 (en) * 2004-09-15 2009-11-10 Nortel Networks Limited Resource conflict management using predefined XML schemas
US7774467B1 (en) * 2004-09-22 2010-08-10 Oracle America Inc. Mechanism for making a computing resource allocation
CN100437495C (zh) * 2004-12-21 2008-11-26 鸿富锦精密工业（深圳）有限公司 解决资源重复锁定冲突系统及方法
WO2006129819A1 (en) 2005-05-31 2006-12-07 Matsushita Electric Industrial Co., Ltd. Broadcast receiving terminal and program execution method
US7454607B2 (en) * 2005-09-15 2008-11-18 Qualcomm Incorporated Techniques for managing applications in a portable communication device
US20070094668A1 (en) * 2005-10-17 2007-04-26 Jacquot Bryan J Method and apparatus for dynamically allocating resources used by software
EP2511833B1 (en) * 2006-02-17 2020-02-05 Google LLC Encoding and adaptive, scalable accessing of distributed translation models
WO2008084904A1 (en) * 2007-01-10 2008-07-17 Samsung Electronics Co., Ltd. Broadcast receiving apparatus and method for focus management by application
US20090222491A1 (en) * 2008-02-28 2009-09-03 Michael Larkin Systems and Methods for Layered Resource Management
US8997080B2 (en) * 2013-02-11 2015-03-31 Citrix Systems, Inc. System updates with personal virtual disks
US9870298B2 (en) * 2013-08-26 2018-01-16 Google Llc Application resource utilization management
JP6310260B2 (ja) * 2014-01-20 2018-04-11 株式会社荏原製作所 基板処理装置内の複数の処理ユニットを調整するための調整装置、および該調整装置を備えた基板処理装置
CN105389203B (zh) 2015-10-19 2017-11-17 广东欧珀移动通信有限公司 一种指纹识别设备的调用方法、装置及移动终端
FR3089316B1 (fr) * 2018-11-30 2020-10-30 Thales Sa Procédé et dispositif de surveillance d’application(s) logicielle(s) avec période temporelle tampon précédant une section réservée pour un ensemble de ressource(s) partagée(s), programme d’ordinateur et système avionique associés

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2650965B2 (ja) * 1988-05-27 1997-09-10 株式会社日立製作所 計算機システムおよびそのタスクスケジュール方法
JPH05120041A (ja) * 1991-10-25 1993-05-18 Nec Corp 資源割り当て管理方式
EP0543560B1 (en) 1991-11-19 1999-12-22 Sun Microsystems, Inc. Arbitrating multiprocessor accesses to shared resources
EP0576764A1 (en) * 1992-06-30 1994-01-05 International Business Machines Corporation Method and apparatus for managing the access to a resource by several users in a data processing system
US5748468A (en) * 1995-05-04 1998-05-05 Microsoft Corporation Prioritized co-processor resource manager and method
JPH0954699A (ja) * 1995-08-11 1997-02-25 Fujitsu Ltd 計算機のプロセススケジューラ
JP3259620B2 (ja) * 1995-12-21 2002-02-25 株式会社日立製作所 資源割り当て方法
US6598068B1 (en) 1996-01-04 2003-07-22 Sun Microsystems, Inc. Method and apparatus for automatically managing concurrent access to a shared resource in a multi-threaded programming environment
IE960753A1 (en) * 1996-10-29 1998-05-06 Sportables Limited A method and apparatus for controlling access by two¹computer processors to a shared resource
FR2762418B1 (fr) 1997-04-17 1999-06-11 Alsthom Cge Alcatel Procede de gestion d'une memoire partagee
US6253273B1 (en) * 1998-02-06 2001-06-26 Emc Corporation Lock mechanism
US6330612B1 (en) * 1998-08-28 2001-12-11 International Business Machines Corporation Method and apparatus for serializing access to a shared resource in an information handling system
US20020029213A1 (en) * 2000-02-17 2002-03-07 Roumen Borissov Method and system for resource allocation

Also Published As

Publication number Publication date
US20020007408A1 (en) 2002-01-17
EP1187019A3 (en) 2002-09-11
ATE520077T1 (de) 2011-08-15
US7150020B2 (en) 2006-12-12
GB2364143A (en) 2002-01-16
EP1187019B1 (en) 2011-08-10
GB0016152D0 (en) 2000-08-23
EP1187019A2 (en) 2002-03-13

Similar Documents

Publication Publication Date Title
ES2367886T3 (es) Gestión de recursos.
US9122575B2 (en) Processing system having memory partitioning
US9411646B2 (en) Booting secondary processors in multicore system using kernel images stored in private memory segments
EP0661633B1 (en) Method and system for managing ownership of a released synchronization mechanism
ES2830355T3 (es) Procedimiento, dispositivo y sistema para implementar el procesamiento de aceleración de hardware
US7752620B2 (en) Administration of locks for critical sections of computer programs in a computer that supports a multiplicity of logical partitions
CN104160380B (zh) 一种存储池中的磁盘所有权仲裁方法及节点群集
US8904400B2 (en) Processing system having a partitioning component for resource partitioning
US20060130062A1 (en) Scheduling threads in a multi-threaded computer
JP2017519308A (ja) マルチテナントアプリケーションサーバ環境におけるワークマネージャを提供するためのシステムおよび方法
EP3470984B1 (en) Method, device, and system for managing disk lock
US20110219371A1 (en) Managing and Reporting Conflicts Between Multiple Users Accessing A Logically Partitioned Computer System
US20240370313A1 (en) Multi-phase distributed task coordination
KR102132218B1 (ko) 신뢰하는 실행 환경에서의 보안 도메인 관리 방법 및 장치
EP1947566A1 (en) Information processing method and information processing apparatus
US7574439B2 (en) Managing a nested request
US20080209168A1 (en) Information Processing Apparatus, Process Control Method, and Computer Program
CN112433669A (zh) 一种分布式存储卷在线迁移的方法、系统、设备及介质
JP4972171B2 (ja) 仮想環境割り当てシステム及び仮想環境割り当て方法
KR20060002822A (ko) 저장 제어 장치 및 그의 동작 방법
CN114579321B (zh) 分布式锁的实现方法及装置
JP2020503618A (ja) 仮想メモリを管理する方法
US10515027B2 (en) Storage device sharing through queue transfer
JP2588175B2 (ja) ハツシユ・テ−ブル・エントリ排他処理装置
CN119292767B (zh) 一种仿真环境的动态配置系统、装置及可读存储介质