ES2439803B1 - Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático - Google Patents

Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático Download PDF

Info

Publication number
ES2439803B1
ES2439803B1 ES201230580A ES201230580A ES2439803B1 ES 2439803 B1 ES2439803 B1 ES 2439803B1 ES 201230580 A ES201230580 A ES 201230580A ES 201230580 A ES201230580 A ES 201230580A ES 2439803 B1 ES2439803 B1 ES 2439803B1
Authority
ES
Spain
Prior art keywords
service
programming interface
application
application programming
execution
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.)
Active
Application number
ES201230580A
Other languages
English (en)
Other versions
ES2439803A1 (es
Inventor
Manuel Alejandro PAJUELO GONZÁLEZ
Javier VERDÚ MULÁ
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.)
Universitat Politecnica de Catalunya UPC
Original Assignee
Universitat Politecnica de Catalunya UPC
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
Priority to ES201230580A priority Critical patent/ES2439803B1/es
Application filed by Universitat Politecnica de Catalunya UPC filed Critical Universitat Politecnica de Catalunya UPC
Priority to HUE13777888A priority patent/HUE041417T2/hu
Priority to KR1020147032131A priority patent/KR102057360B1/ko
Priority to DK13777888.2T priority patent/DK2840496T3/en
Priority to US14/395,488 priority patent/US9195505B2/en
Priority to PCT/ES2013/070248 priority patent/WO2013156655A1/es
Priority to ES13777888T priority patent/ES2697681T3/es
Priority to CN201380031821.5A priority patent/CN104364759B/zh
Priority to JP2015506270A priority patent/JP2015517159A/ja
Priority to EP13777888.2A priority patent/EP2840496B1/en
Publication of ES2439803A1 publication Critical patent/ES2439803A1/es
Application granted granted Critical
Publication of ES2439803B1 publication Critical patent/ES2439803B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Stored Programmes (AREA)

Abstract

Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático.#La invención se refiere a un procedimiento para controlar el uso de recursos de hardware de un sistema informático por parte de una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, mediante una pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a la aplicación, comprendiendo el procedimiento interceptar la llamada del proceso al servicio de la api; actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la API.

Description

imagen1
interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, mediante una pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a la aplicación.
La invención se refiere también a un sistema y a la pieza de código ejecutable adecuados para llevar a cabo este procedimiento.
Antecedentes de la invención
Desde hace ya algunos años, es conocido que la evolución de la informática tanto a nivel de software como de hardware es imparable.
A nivel de hardware, por ejemplo, los procesadores son cada vez más rápidos e integran nuevos avances, mientras que las memorias (volátiles y no volátiles) cada vez tienen una mayor capacidad de almacenamiento.
Del mismo modo, a nivel de software, las aplicaciones (por ejemplo, los sistemas operativos, las aplicaciones ofimáticas o de dibujo asistido por ordenador, o los juegos) cada vez son más potentes e implementan mayores funcionalidades, algunas de las cuales eran impensables hace unos años.
El principal inconveniente de esta situación aparece cuando se pierde el equilibrio entre las características de los recursos de hardware del sistema informático del usuario y los requerimientos de hardware del software con el que trabaja. Hasta el día de hoy, no está muy claro si el software evoluciona tan rápidamente porque los programadores saben que disponen cada vez de mayores recursos de hardware, o si es imprescindible una evolución del hardware para poder asumir los requerimientos cada vez mayores de los diferentes software implementados. Si el software que se pretende utilizar tiene unos requerimientos de hardware igual o superiores a las características de los recursos de los que dispone el sistema informático del usuario, la problemática en el funcionamiento del mismo es clara y evidente. Además, hay que pensar que los requerimientos de hardware de un software determinado se establecen teniendo en cuenta que ese software se ejecutará en solitario sobre el sistema informático, pero ésta es una situación poco habitual porque, como mínimo, es más que posible que haya software ejecutándose en segundo plano, el cual obviamente también estará consumiendo recursos de hardware del sistema (por ejemplo, un antivirus, un firewall, o un software de copias de seguridad).
Lo que parece claro es que los programadores de software no acostumbran a tener en cuenta que la mayor parte de los sistemas informáticos de los usuarios no disponen de recursos de hardware de última tecnología y que con cada nuevo software o con cada actualización de software ya existente están provocando que los usuarios tengan que actualizar estos recursos de hardware e incluso adquirir nuevos sistemas informáticos con la intención de poder como mínimo ejecutar ese software y obtener un rendimiento adecuado del mismo. Todo ello, al final, supone un coste económico elevado para los usuarios, no sólo para la adquisición del software, sino también para la actualización de los recursos de hardware de su sistema.
Esta problemática también está presente en sistemas informáticos tipo servidores (ya sean de aplicaciones, de datos, etc.). Un aumento de los requerimientos de hardware por parte de un software de servidor (por ejemplo, después de una actualización) puede suponer que este servidor no pueda dar servicio a la totalidad de usuarios que estaba gestionando hasta ese momento, si no se ha realizado previamente una actualización de los recursos de hardware de los que dispone. Del mismo modo, si se trata por ejemplo de un servidor de aplicaciones, para poder dar servicio al mismo número de usuarios es posible que tenga que reducir el número de aplicaciones que gestiona. Es importante destacar que en el caso de sistemas tipo servidor el coste económico de esta actualización de los recursos de hardware es aún mayor que la que se produce en la situación descrita anteriormente, puesto que los recursos de hardware para un sistema informático tipo servidor tienen unos costes más elevados.
Por otro lado, también puede darse la situación en la que, dado un sistema informático con unos recursos de hardware determinados, se pretenda ejecutar sobre él un mayor número de aplicaciones y/o de instancias de una misma aplicación del que teóricamente podría ejecutar. En esta situación, los recursos de hardware son los que son y, por lo tanto, es necesario actuar sobre la ejecución de las aplicaciones y/o de las diferentes instancias de una misma aplicación para reducir el consumo de los recursos de hardware que utilizan.
Sea cual sea la situación de entre las descritas anteriormente, el sistema operativo no es capaz de controlar de manera efectiva el uso de los recursos de hardware que realizan las aplicaciones y/o las instancias de una misma aplicación durante su ejecución, por lo que es necesaria una herramienta para ello.
imagen2
sobre el que se ejecuta la aplicación.
Este objetivo se consigue proporcionando un procedimiento para controlar el uso de recursos de hardware de un sistema informático por parte de una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, mediante una pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a la aplicación, comprendiendo el procedimiento:
-Interceptar una llamada del proceso perteneciente a la aplicación a un servicio de la interfaz de programación de aplicaciones;
-Actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones.
De este modo, mediante la pieza de código ejecutable que se inyecta en el proceso se interceptan las comunicaciones (tanto de señales de control como de datos) entre la aplicación en ejecución y el sistema operativo, de manera que la pieza de código actúa por encima del sistema operativo y puede gestionar o controlar entidades software pertenecientes al proceso y reducir el uso de los recursos de hardware por parte del mismo.
Básicamente, la pieza de código ejecutable que se inyecta en el proceso perteneciente a la aplicación aporta inteligencia a la hora de controlar el uso que una aplicación realiza de los recursos de hardware del sistema informático sobre el que se ejecuta. Obviamente, el control que realiza la pieza de código reduce el uso de recursos de hardware, pero siempre manteniendo una mínima calidad de servicio.
Como resultado de todo ello, esta reducción en el uso de recursos de hardware por parte de una aplicación puede suponer que estos recursos pueden ser utilizados por otras aplicaciones (o varias instancias de una misma aplicación) y, por lo tanto, que pueden ejecutarse simultáneamente más aplicaciones por sistema informático, aumentándose la eficiencia del mismo.
Del mismo modo, esta reducción en el uso de recursos de hardware por parte de una aplicación puede suponer que una aplicación con unos requerimientos de hardware superiores a los ofrecidos por un sistema informático, también pueda ser ejecutada.
Es importante destacar que las expresiones “un servicio”, “una interfaz de programación de aplicaciones” o “una entidad software” se refieren a al menos un servicio, a al menos una interfaz de programación de aplicaciones, y/o a al menos una entidad software, respectivamente. Así, por ejemplo, es posible redireccionar dos servicios de una misma interfaz de programación de aplicaciones hacia dos servicios comprendido en la pieza de código, o redireccionar un servicio de una primera interfaz de programación de aplicaciones a un primer servicio comprendido en la pieza de código y un servicio de una segunda interfaz de programación de aplicaciones a un segundo servicio comprendido en la pieza de código. Del mismo modo, dependiendo de los servicios redireccionados, es posible que la pieza de código actúe sobre una o más entidades software, tales como hilos de ejecución, memoria o cierres de exclusión mutua, entre otros.
Una manera de cómo inyectar la pieza de código ejecutable en el proceso se describe por ejemplo en [“Windows NT System-Call Hooking”, Mark Russinovich and Bryce Cogswell, Dr. Dobb’s Journal, January 1997].
Es importante destacar que la inyección de la pieza de código en el proceso puede realizarse con el proceso iniciado en estado de suspensión, lo que asegura el correcto funcionamiento de la pieza de código. En este caso, el procedimiento puede comprender una etapa de reanudar la ejecución del proceso que se encuentra en estado de suspensión.
Por otro lado, también es importante destacar que el término “interceptar” se refiere al hecho que la llamada del proceso al servicio de la interfaz de programación de aplicaciones supone una redirección a un servicio comprendido en la pieza de código, de manera que la propia pieza de código es capaz de controlar o actuar sobre entidades software pertenecientes al proceso y así controlar el uso de recursos por parte de la aplicación.
Además, el procedimiento puede comprender redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código, de manera que se consigue, de
imagen3
•
Cargar en memoria la librería de enlace dinámico que comprende la función de la interfaz de programación de aplicaciones a redireccionar;
•
Sustituir, en la tabla de punteros a las funciones de la interfaz de programación de aplicaciones comprendidas en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena la función de la interfaz de programación de aplicaciones a redireccionar por la dirección de memoria inicial en la que se almacena la función correspondiente comprendida en la pieza de código.
De este modo, se realiza una redirección de una o más funciones de cada interfaz de programación de aplicaciones hacia funciones comprendidas en la pieza de código, de manera que ésta puede interceptar las llamadas a estas funciones por parte del proceso y así controlar el uso de recursos hardware que supone su ejecución, mediante la actuación sobre entidades software, tales como hilos de ejecución, memoria o cierres de exclusión mutua (también conocidos como candados), entre otros.
Preferiblemente, la etapa de redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código puede comprender almacenar en una primera variable la dirección de memoria inicial en la que se almacena la función de la interfaz de programación de aplicaciones a redireccionar. De este modo, es posible realizar una llamada a la función de la interfaz de programación de aplicaciones (es decir, a la función original) desde la propia pieza de código ejecutable, en el caso que sea necesario en algún momento durante la ejecución de la aplicación.
De acuerdo con otra realización preferida de la invención, el servicio de una interfaz de programación de aplicaciones puede ser un método de un objeto, y la etapa de redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código puede comprender:
•
Cargar en memoria la librería de enlace dinámico que comprende el método del objeto a redireccionar;
•
Verificar si el objeto asociado al método a redireccionar se crea por primera vez;
•
En caso de resultado positivo en la verificación,
o Sustituir, en la tabla de punteros a los métodos del objeto comprendidos en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar, por la dirección de memoria inicial en la que se almacena el método correspondiente comprendido en la pieza de código.
Igual que en el caso de las funciones, también es posible redireccionar uno o más métodos pertenecientes a un objeto hacia uno o más métodos comprendidos en la pieza de código, de manera que ésta puede interceptar las llamadas a estos métodos por parte del proceso y así controlar el uso de recursos hardware que supone su ejecución.
Puesto que, como se ha comentado anteriormente, es posible redireccionar al menos un servicio de al menos una interfaz de programación de aplicaciones, se puede dar el caso que uno de los servicios sea una función y otro de los servicios sea un método, de manera que las dos realizaciones expuestas pueden llegar a ser complementarias para una misma aplicación en ejecución.
También preferiblemente, la etapa de redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código puede comprender almacenar en una segunda variable la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar, de modo que, si se requiere, podrá llamarse a este método (es decir, el método original) desde la propia pieza de código.
De acuerdo con una realización de la invención, el servicio de la interfaz de programación de aplicaciones puede ser un servicio relacionado con la entidad software perteneciente al proceso, pudiendo estar este servicio destinado a la creación de nuevos hilos de ejecución; la entidad software puede ser un hilo de ejecución; y la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
• Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para generar un nuevo hilo de ejecución;
imagen4
un servicio relacionado con la entidad software perteneciente al proceso, estando este servicio destinado a la creación de nuevos hilos de ejecución; la entidad software puede ser un hilo de ejecución; y la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
•
Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para generar un nuevo hilo de ejecución;
•
Realizar una llamada al servicio de la interfaz de programación de aplicaciones, a partir de la dirección de memoria inicial almacenada en la primera variable si el servicio es una función o en la segunda variable si el servicio es un método;
•
Recibir un identificador del nuevo hilo de ejecución generado por la función de la interfaz de programación de aplicaciones;
•
Guardar el identificador del hilo de ejecución generado en una tercera variable que mantiene el registro de los hilos de ejecución creados.
Dado que es posible que se redireccione más de un servicio relacionado con una entidad software del tipo hilo de ejecución, las dos realizaciones descritas no son alternativas sino que pueden llegar a ser complementarias.
Más concretamente, en la primera realización descrita, el servicio para generar un nuevo hilo de ejecución está comprendido en la propia pieza de código, mientras que en la segunda realización, el servicio para generar un nuevo hilo de ejecución no está comprendido en la pieza de código y es necesario realizar una llamada al servicio original de la interfaz de programación de aplicaciones para conseguir la generación del hilo de ejecución. Para ello es necesario haber almacenado previamente la dirección de memoria en la que se almacena el servicio de la interfaz de programación de aplicaciones (es decir, el servicio original) en la primera variable descrita anteriormente si el servicio es una función o en la segunda variable descrita si el servicio es un método. A pesar de todo, sea cual sea la realización implementada, la pieza de código es la que gestiona el identificador del nuevo hilo de ejecución creado, almacenándolo en la tercera variable que mantiene el registro de los hilos de ejecución creados.
En el caso que la entidad software sea un hilo de ejecución, la etapa de actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
•
Determinar un valor de rendimiento de la aplicación en ejecución;
•
Verificar si este valor de rendimiento de la aplicación supera un valor umbral;
•
En caso de resultado positivo, parar durante un tiempo predeterminado los hilos de ejecución, a partir de los identificadores almacenados en la tercera variable que mantiene el registro de los hilos de ejecución creados.
Puesto que la gestión de los identificadores de los hilos de ejecución la realiza la pieza de código, en el caso que la pieza de código (más concretamente, un algoritmo comprendido en la pieza de código) detecte que el rendimiento de la aplicación está por encima de un valor umbral (es decir, en el caso que la ejecución de la aplicación esté consumiendo demasiados recursos o recursos innecesarios), la pieza de código puede provocar la parada de la ejecución de los hilos creados hasta el momento a partir de sus identificadores almacenados en la tercera variable, lo que significa que la pieza de código puede ser capaz de controlar el uso de los recursos de hardware consumidos por la aplicación.
La etapa de determinar un valor de rendimiento de la aplicación en ejecución a partir del uso de recursos de hardware que realiza puede comprender:
o Establecer como punto de control un servicio de una interfaz de programación de aplicaciones que el proceso, durante su ejecución, va a llamar iterativamente;
o Determinar el tiempo transcurrido entre una primera llamada y una segunda llamada a este servicio, por parte del proceso;
imagen5
Por otro lado, para determinar el tiempo en el que deben estar parados los hilos de ejecución se puede utilizar cualquier algoritmo que mida la diferencia de tiempo de ejecución necesario para mantener el rendimiento obtenido con respecto al tiempo requerido para mantener el rendimiento deseado. Este algoritmo puede estar comprendido en la pieza de código, aunque también puede realizarse una llamada a un algoritmo externo desde la pieza de código.
En el caso que la entidad software esté relacionada con la memoria y el servicio de la interfaz de programación de aplicaciones sea un servicio destinado a la reserva de zonas de memoria, la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
• Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para reservar una zona de memoria.
Además, en este caso, la etapa de actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
• Reservar una zona de memoria compartida.
De este modo, cuando el proceso llama al servicio de la interfaz de programación de aplicaciones para reservar una zona de memoria, se intercepta esta llamada (es decir, se redirecciona la llamada a un servicio correspondiente comprendido en la pieza de código) y se asigna una zona de memoria destinada a ser compartida por diferentes instancias de una misma aplicación.
En este punto es importante destacar la necesidad de identificar (o mapear) qué zonas de memoria compartida deben reservarse. Así, por ejemplo, si una instancia de una aplicación reserva tres zonas de memoria i, j, k y las asigna a tres variables determinadas (A, B, C, respectivamente) y todas cumplen la condición de poder ser compartidas, una segunda instancia de la aplicación debe asignar correctamente las zonas compartidas a las tres variables (A, B, C), es decir, debe asignar las zonas a las variables en el orden correcto (i, j, k a las variables A, B, C, respectivamente), puesto que cualquier otro orden (por ejemplo, k, i, j) puede suponer una ejecución incorrecta de la instancia de la aplicación.
A continuación se plantea un ejemplo para mostrar de manera clara cómo la pieza de código controla el uso de los recursos de hardware durante la ejecución de una aplicación, cuando la entidad software es la memoria.
Si se parte de una aplicación que requiere, por ejemplo, 1 gigabyte de memoria para su ejecución, la ejecución de una segunda instancia de esta aplicación supondría un gigabyte adicional, es decir, la ejecución de las dos instancias supondría un total de 2 gigabytes de memoria consumida. En el caso de inyectar en ambas instancias de la aplicación la pieza de código ejecutable objeto de la invención, el consumo de memoria podría ser inferior a los 2 gigabytes, puesto que podrían asignarse zonas de memoria compartidas por diferentes instancias en ejecución. En este punto, es necesario aclarar que en la mayor parte de casos puede que no sea posible compartir la totalidad de la memoria requerida (1 gigabyte en el presente ejemplo) por cada instancia de la aplicación, puesto que puede existir información en determinadas zonas de memoria que no debería ser modificada por otras instancias de la aplicación. Por lo tanto, previamente a la asignación de las zonas de memoria, debería existir una identificación de las zonas de memoria que no deberían ser modificadas por contener información propia de cada instancia.
Por otro lado, también es posible que la llamada del proceso al servicio correspondiente comprendido en la pieza de código suponga una llamada desde esta pieza de código a la función de la interfaz de programación de aplicaciones original destinada a la reserva de una zona de memoria, realizándose esta llamada a partir de la dirección de memoria almacenada en la primera variable comentada anteriormente si el servicio es una función o en la segunda variable descrita si el servicio es un método.
Por otro lado, en el caso que la entidad software sea un cierre de exclusión mutua o candado (en inglés, lock) y que el servicio de la interfaz de programación de aplicaciones sea un servicio destinado a intervenir sobre un cierre de exclusión mutua, la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
• Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para intervenir sobre un cierre de exclusión mutua.
imagen6
aplicación sobre un mismo sistema informático. Para ello utilizan cierres de exclusión mutua o candados, los cuales asignan un identificador a la instancia de la aplicación en ejecución y, dado que cualquier nueva instancia que se pretenda generar recibirá el mismo identificador, hace inviable ejecutar más de una instancia.
Ante esta situación, y tal como se ha descrito arriba, cuando el proceso pretende crear el cierre de exclusión mutua asociado a la aplicación y llama al servicio correspondiente comprendido en la pieza de código (previamente se habrá redireccionado el puntero del servicio de la interfaz de programación de aplicaciones original destinado a esta acción, al servicio comprendido en la pieza de código), la pieza de código provoca una modificación del identificador asignado al cierre de exclusión mutua, de manera que cuando se genera una segunda instancia de la aplicación los identificadores no coinciden y se permite su ejecución simultánea.
De acuerdo con otro aspecto de la invención, se proporciona una pieza de código ejecutable que comprende instrucciones para ejecutar un procedimiento para controlar el uso de recursos de hardware de un sistema informático descrito anteriormente, estando esta pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a una aplicación, cuando esta aplicación se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático.
Esta pieza de código ejecutable puede estar almacenada en unos medios de almacenamiento físico, tales como unos medios de grabación, una memoria de ordenador, o una memoria de solo lectura, o puede ser portada por una onda portadora, tal como eléctrica u óptica.
Además, la invención proporciona un procedimiento para ejecutar una aplicación sobre un sistema informático, que puede comprender:
-Iniciar la ejecución de un proceso asociado a la aplicación, en un estado de suspensión;
-Inyectar la pieza de código ejecutable descrita anteriormente, en el proceso en estado de suspensión;
-Ejecutar el procedimiento descrito anteriormente para controlar el uso de recursos de hardware de un sistema informático por parte de la aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, mediante la pieza de código ejecutable inyectada en el proceso.
De este modo, cuando un usuario solicita la ejecución de una aplicación sobre un sistema informático, ésta puede ejecutarse de acuerdo con el procedimiento descrito, con la intención que la pieza de código controle el uso de los recursos de hardware.
De acuerdo con otro aspecto de la invención, se proporciona un sistema para controlar el uso de recursos de hardware de un sistema informático por parte de una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, estando el sistema adaptado para ser inyectado en un proceso perteneciente a la aplicación, comprendiendo el sistema:
-Medios informáticos para interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones;
-Medios informáticos para actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones.
De acuerdo con aún otro aspecto, la invención proporciona un sistema informático sobre el que puede ejecutarse una aplicación, que puede comprender una memoria y un procesador, que puede incorporar instrucciones almacenadas en la memoria y que pueden ser ejecutables por el procesador, pudiendo comprender las instrucciones funcionalidades para:
-Iniciar la ejecución de un proceso asociado a la aplicación, en un estado de suspensión;
-Inyectar la pieza de código ejecutable descrita anteriormente, en el proceso en estado de suspensión; características de la invención se desprenderán en parte de la descripción y en parte de la práctica de la invención. Los ejemplos y dibujos se proporcionan a modo de ilustración, y no se pretende que sean limitativos de la presente invención. Los signos numéricos relativos a los dibujos y colocados entre paréntesis en una reivindicación, son solamente para intentar aumentar la comprensión de la reivindicación, y no deben ser interpretados como limitantes del alcance de la protección de la reivindicación. Además, la presente invención cubre todas las posibles combinaciones de realizaciones particulares y preferidas aquí indicadas.
imagen7
Breve descripción de los dibujos
Para mayor comprensión de cuanto se ha expuesto se acompaña unos dibujos en los cuales, esquemáticamente y sólo a título de ejemplo no limitativo, se representan unos casos prácticos de realización.
En los dibujos,
La figura 1 es un diagrama de bloques que representa las capas de ejecución de una aplicación sobre un sistema informático, de acuerdo con el estado de la técnica;
La figura 2 es un diagrama de bloques que representa las capas de ejecución de una aplicación sobre un sistema informático y que incorpora además una capa representativa de una pieza de código ejecutable inyectada en un proceso perteneciente a la aplicación, estando esta pieza de código destinada a controlar el uso de recursos de hardware de un sistema informático por parte de la aplicación, de acuerdo con la invención.
Descripción de una realización preferida de la invención
A continuación se realizará la descripción de un procedimiento y de una pieza de código ejecutable de acuerdo con la invención para controlar el uso de recursos de hardware de un sistema informático por parte de una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones (API) y que se ejecuta sobre este sistema informático, estando esta pieza de código adaptada para ser inyectada en un proceso asociado a la aplicación, cuyo proceso ha sido iniciado en un estado de suspensión.
La Figura 1 muestra un diagrama que representa las capas de ejecución de una aplicación (por ejemplo, un juego) sobre un sistema informático (por ejemplo, un ordenador personal, un servidor, etc.), de acuerdo con el estado de la técnica.
En este diagrama, la capa 10 de más bajo nivel representa los recursos de hardware del sistema informático tales como el microprocesador (CPU), la memoria, la unidad de procesamiento gráfico (GPU), el teclado o el ratón, entre otros.
En una segunda capa 11 dispuesta en un nivel superior se encuentra el sistema operativo, que cuenta con los controladores necesarios para comunicarse e interactuar de manera bidireccional (puede mandar y/o recibir información de estos recursos, tal como señales de control 14 o datos 15) con los recursos de la capa inferior 10.
En una tercera capa 12 dispuesta por encima de la capa 11 representativa del sistema operativo se encuentran las interfaces de programación de aplicaciones (más conocidas como API), tanto las que vienen comprendidas en el sistema operativo como aquellas que son el resultado de la instalación de los controladores de un recurso de la capa inferior 10. Normalmente, estas API están implementadas dentro de librerías de enlace dinámico, sea cual sea el sistema operativo utilizado. La comunicación entre la capa 12 que comprende las API y la capa 11 representativa del sistema operativo es también bidireccional, pudiendo intercambiar tanto señales de control 14 como datos 15.
Finalmente, en La Figura 1 se muestra también una cuarta capa o capa de nivel superior 13 que representa la aplicación en ejecución. Esta aplicación, durante su ejecución, accede a la capa 12 representativa de las API, intercambiando tanto señales de control como datos.
De este modo, de acuerdo con esta configuración, si, por ejemplo, la aplicación en ejecución 13 requiere de la generación de una ventana en la pantalla de visualización del sistema informático sobre el que se está ejecutando, la aplicación debe acceder a determinados servicios de las API 12 (ya sean funciones o métodos) destinados a la generación de ventanas. Estos servicios, para poder generar la ventana en la pantalla, necesitan intercambiar información (señales de control y datos) con el sistema operativo 11, el cual dispone de las herramientas necesarias (es decir, controladores) para comunicarse con la pantalla 10 y provocar, así, la generación de la ventana deseada.
imagen8
La Figura 2 muestra un diagrama basado en el de la Figura 1 pero que además comprende una capa 16 que representa la pieza de código ejecutable que, después de ser inyectada en el proceso asociado a la aplicación, se dispone a nivel lógico entre la capa 13 de la aplicación y la capa 12 representativa de las API, de manera que la pieza de código puede interceptar las llamadas de la aplicación a determinados servicios (por ejemplo, funciones o métodos) de las API y controlar así el uso de recursos de hardware por parte de la aplicación actuando sobre una o más entidades software pertenecientes al proceso.
Más concretamente, el procedimiento que ejecuta la pieza de código es el siguiente. Para su descripción, se parte de una situación inicial en la que, cuando un usuario ejecuta una aplicación, el proceso perteneciente a la aplicación se inicia en un estado suspendido. Durante este estado de suspensión, la pieza de código ejecutable se inyecta en el proceso.
Una vez inyectada la pieza de código en el proceso, esta pieza de código carga en memoria todas aquellas librerías de enlace dinámico que contienen las interfaces de programación de aplicaciones (API) que contienen aquellos servicios (ya sea funciones o métodos) que van a ser requeridos por la aplicación durante su ejecución. A continuación, después que el sistema operativo haya rellenado la tabla de punteros a los servicios de las diferentes API cargadas en memoria de acuerdo con las direcciones de memoria iniciales en las que se han almacenado estos servicios, sustituye en esta tabla de punteros la dirección de memoria inicial de cada uno de los servicios que pueden o van a ser requeridos por la aplicación durante su ejecución por la dirección de memoria inicial en la que se encuentra cada uno de los servicios correspondientes comprendidos en la pieza de código. De este modo, a partir de esta redirección realizada, la pieza de código es capaz de interceptar las llamadas que el proceso realiza a estos servicios relevantes para su ejecución, es decir, las llamadas que el proceso realiza a los diferentes servicios relevantes de las diferentes API son recibidas por la pieza de código, puesto que los punteros no apuntan a los servicios de las API sino a los servicios correspondientes comprendidos en la pieza de código.
A partir de la interceptación comentada, la pieza de código adquiere la capacidad de controlar el uso de los recursos de hardware del sistema informático que realiza la aplicación, es decir, la pieza de código toma el control, de forma transparente para el proceso, del uso que la aplicación realiza de los recursos de hardware del sistema.
Más concretamente, cuando el proceso pretende acceder a un recurso de hardware del sistema informático mediante llamadas a determinados servicios de las API, la pieza de código ejecuta sus propios servicios (es decir, realiza una interceptación de estas llamadas). A partir de esta interceptación, la pieza de código actúa sobre una entidad software determinada, dependiendo del tipo de servicio al que el proceso realiza la llamada.
Así, si el servicio de la API que se intercepta es un servicio destinado a la creación de nuevos hilos de ejecución (es decir, la entidad software sobre la que la pieza deberá actuar será un hilo de ejecución), la etapa de interceptación puede comprender:
•
Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para generar un nuevo hilo de ejecución;
•
Generar un nuevo hilo de ejecución a partir del servicio correspondiente comprendido en la pieza de código;
•
Guardar el identificador del hilo de ejecución generado en una variable determinada que mantiene el registro de los hilos de ejecución creados.
Para el caso comentado (es decir, si el servicio de la API que se intercepta es un servicio destinado a la creación de nuevos hilos de ejecución) también es posible que interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones pueda comprender de manera alternativa:
•
Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para generar un nuevo hilo de ejecución;
•
Realizar una llamada a la función de la interfaz de programación de aplicaciones, a partir de la dirección de memoria inicial almacenada en la variable destinada a almacenar este tipo de información;
imagen9
ejecución, la etapa de actuar sobre una entidad software puede comprender:
•
Determinar un valor de rendimiento de la aplicación en ejecución;
•
Verificar si este valor de rendimiento de la aplicación supera un valor umbral;
•
En caso de resultado positivo, parar durante un tiempo predeterminado los hilos de ejecución creados previamente, a partir de los identificadores almacenados en la variable destinada a mantener el registro de los hilos de ejecución creados.
De este modo, puesto que la gestión de los identificadores de los hilos de ejecución la realiza la pieza de código (los tiene almacenados en una variable gestionada por ella), en el caso que la pieza de código detecte que el rendimiento de la aplicación está por encima de un valor umbral (es decir, en el caso que la ejecución de la aplicación esté consumiendo demasiados recursos o recursos innecesarios), la pieza de código puede provocar la parada de la ejecución de los hilos creados hasta el momento a partir de sus identificadores almacenados en la variable correspondiente, lo que significa que la pieza de código puede ser capaz de controlar el uso de los recursos de hardware consumidos por la aplicación.
La etapa de determinar un valor de rendimiento de la aplicación en ejecución descrita puede comprender:
o Establecer como punto de control un servicio de una interfaz de programación de aplicaciones que el proceso, durante su ejecución, va a llamar iterativamente;
o Determinar el tiempo transcurrido entre una primera llamada y una segunda llamada a este servicio, por parte del proceso;
o Obtener un valor del rendimiento de la aplicación en ejecución a partir del tiempo determinado.
En el caso que el servicio de la API interceptado sea un servicio destinado a la reserva de zonas de memoria, la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
• Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para reservar una zona de memoria.
En este caso (es decir, la llamada interceptada es a un servicio destinado a la reserva de zonas de memoria), la etapa de actuar sobre una entidad software perteneciente al proceso en ejecución puede comprender:
• Reservar una zona de memoria compartida.
De este modo, cuando el proceso llama al servicio de la interfaz de programación de aplicaciones para reservar una zona de memoria, se intercepta esta llamada (es decir, se redirecciona la llamada a un servicio correspondiente comprendido en la pieza de código) y se asigna una zona de memoria destinada a ser compartida por diferentes instancias de una misma aplicación, es decir, el servicio correspondiente comprendido en la pieza de código es el que asigna al proceso una zona de memoria destinada a ser compartida por diferentes instancias de una misma aplicación.
Finalmente, si la llamada interceptada corresponde a un servicio de la API destinado a intervenir sobre un cierre de exclusión mutua, la etapa de interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
•
Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para intervenir sobre un cierre de exclusión mutua;
•
Modificar el nombre asignando al cierre de exclusión mutua;
mientras que la etapa de actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones puede comprender:
imagen10
Ante esta situación, y tal como se ha descrito arriba, cuando el proceso pretende crear el cierre de exclusión mutua asociado a la aplicación y llama al servicio correspondiente comprendido en la pieza de código (previamente se habrá redireccionado el puntero del servicio de la interfaz de programación de aplicaciones original destinado a esta acción, al servicio comprendido en la pieza de código), la pieza de código provoca una modificación del identificador asignado al cierre de exclusión mutua, de manera que cuando se genera una segunda instancia de la aplicación los identificadores no coinciden y se permite su ejecución simultánea.
Por consiguiente, queda claro de lo descrito hasta el momento que la pieza de código es capaz de controlar el uso de los recursos de hardware del sistema informático por parte de la aplicación, a partir de las llamadas que intercepta a diferentes tipos de servicio de las API, actuando sobre entidades software que se corresponden con estos tipos de servicio.
A continuación se describirá una realización preferida de la invención, en la que el sistema operativo es uno cualquiera de la familia Windows, por ejemplo, Windows 7; el sistema informático es un servidor de aplicaciones, más concretamente de juegos; y las aplicaciones a ejecutar son juegos y/o diferentes instancias de un mismo juego. Además, la entidad software sobre la que interviene la pieza de código para controlar el uso de recursos de hardware por parte de la aplicación corresponde a los diferentes hilos de ejecución que se han creado hasta el momento, durante la ejecución del proceso.
Más concretamente, la presente realización preferida presenta el siguiente funcionamiento. El servidor de juegos tiene como objetivo permitir a los usuarios del servicio jugar a diferentes juegos o incluso al mismo juego de ordenador desde sus terminales móviles, tales como smartphones o tabletas. La ejecución de cada juego o de cada instancia del mismo juego puede ser enviada mediante técnicas de streaming desde el servidor de juegos a los dispositivos móviles de los usuarios. De este modo, un usuario, desde su dispositivo móvil, puede seleccionar el juego al que desea jugar, solicitando su ejecución mediante la actuación sobre un elemento de control (por ejemplo, un icono representativo del juego) de una interfaz gráfica de usuario mostrada en la pantalla de su terminal móvil. Esta actuación del usuario sobre el elemento de control genera una señal de control hacia el servidor de juegos que provoca la ejecución del juego seleccionado sobre el servidor.
Dado que el número de usuarios que solicitan la ejecución de un juego puede ser elevado (es decir, puede haber un número elevado de juegos en ejecución), la presente invención pretende controlar la ejecución de cada juego para que los recursos de hardware utilizados sean los mínimos posibles, de manera que se puedan ejecutar el máximo número de juegos simultáneamente y, por lo tanto, se pueda dar servicio al máximo número de usuarios.
Así, cuando un usuario solicita la ejecución de un juego desde su terminal móvil, en el servidor de juegos se crea el proceso principal de la aplicación en ejecución (es decir, el juego), en estado suspendido. Para ello se utiliza la función CreateProcess, asignando al parámetro de modo de creación (CreateFlags) el valor CREATE_SUSPENDED. Una vez el proceso se ha iniciado en estado suspendido, se realiza la inyección de la pieza de código de acuerdo con la invención en el proceso, que tiene como objetivo optimizar entidades software pertenecientes al proceso.
Antes de reanudar la ejecución del proceso (hay que recordar que el proceso se inicia en estado suspendido), la pieza de código inyectada redirecciona las funciones de las API que se pretenden interceptar. De acuerdo con la presente realización preferida, se pretenden interceptar dos categorías de funciones:
•
Para registrar la creación de hilos de ejecución, mediante la función CreateThread;
•
Para establecer puntos de control durante la ejecución del proceso. De este modo, utilizando estos puntos de control, puede medirse el rendimiento de la aplicación de forma transparente al proceso, mediante funciones que, a priori, sea conocido que se van a llamar iterativamente a lo largo de la ejecución de todo el proceso. Así, por ejemplo, en aplicaciones gráficas, se puede establecer como punto de control la función que presenta cada fotograma por pantalla, mediante el método Present1 de la API IDXGISwapChain1, de manera que se obtenga el rendimiento de la aplicación midiendo el número de fotogramas mostrados por segundo (FPS – en inglés, Frames Per Second). El objetivo es que la pieza de código inyectada identifique cuándo la aplicación ha sobrepasado un umbral de rendimiento predeterminado, para evitar que utilice en exceso los recursos de hardware del sistema informático (es decir, el servidor de juegos) y, de este modo, balancear el rendimiento junto al de otras aplicaciones (es decir, juegos o instancias del mismo juego) en ejecución. Cuando el rendimiento de la aplicación supere el umbral predeterminado, pueden detenerse los
imagen11
Index Address Table (IAT), que es una tabla de punteros a las funciones de la API, con las direcciones iniciales en memoria de las funciones de la API. Mediante la función RedirectIAT se modifican los punteros necesarios haciendo que éstos correspondan a las funciones pertenecientes a la pieza de código inyectada en el proceso. A la vez, el contenido original de la tabla (es decir, el puntero a la posición de memoria inicial en la que se almacena la función) se guarda en una variable por si se tiene que llamar en algún momento a la función original.
Por otro lado, como la API IDXGISwapChain1 es una interfaz de tipo COM, es necesario modificar la tabla de punteros de la interfaz para sustituir los métodos que se desean interceptar, como por ejemplo Present1. La tabla de punteros a métodos de una interfaz de tipo COM se modifica con código específico. Por ejemplo, Present1 corresponde a la posición 4 de la tabla de métodos de la interfaz IDXGISwapChain1 y se tiene que modificar para que apunte a la función comprendida en la pieza de código inyectada. A la vez, el contenido original de esta posición se guarda en una variable por si se tiene que llamar al método original. La modificación de la tabla de punteros de una interfaz de tipo COM únicamente se tiene que realizar la primera vez que se crea un objeto de ese tipo. En el momento que acaba la redirección de los servicios, es decir, todas las funciones o métodos de todas las API necesarias han sido redirigidas, la ejecución del proceso de la aplicación se reanuda.
Cuando el proceso pretende crear un nuevo hilo de ejecución, se ejecuta la función CreateThread, para almacenar información del nuevo hilo que se va a crear. Para ello, la pieza de código realiza una llamada a la función original CreateThread para su ejecución, y la propia pieza de código guarda el identificador del nuevo hilo de ejecución en una variable que mantiene el registro de todos los hilos de ejecución creados hasta ese momento. En la presente realización preferida, se utiliza la función original CreateThread, es decir, desde la pieza de código se realiza una llamada a esta función original de la API a partir de la dirección de memoria almacenada en la variable correspondiente (la variable que almacena los punteros a la posición de memoria inicial en la que se almacena cada función redireccionada), pero también podría darse la situación en la que la pieza de código comprendiera la función para crear hilos de ejecución y no fuera necesario realizar una llamada a una función externa. En cualquiera de los casos, es la pieza de código la que gestiona los identificadores de los hilos de ejecución creados.
Por otro lado, y tal como se ha comentado anteriormente, también es posible medir el rendimiento de la aplicación en ejecución cada vez que el proceso asociado a la aplicación hace una llamada a una función utilizada como punto de control, por ejemplo, en la presente realización preferida, a la función Present1. Para ello, mediante un algoritmo determinado se mide el tiempo transcurrido desde la última llamada a esta función para calcular el rendimiento, por ejemplo con la métrica de FPS (fotogramas por segundo – en inglés, Frames Per Second). Si el algoritmo de medición de rendimiento comprendido en la pieza de código inyectada identifica que se ha superado un predeterminado valor umbral, se calcula el tiempo necesario que deben estar detenidos los hilos de ejecución. Este tiempo es posible calcularlo mediante un algoritmo que mida la diferencia de tiempo de ejecución necesario para mantener el rendimiento actual con respecto al tiempo requerido para mantener el rendimiento deseado. A continuación, la pieza de código provoca la parada de todos los hilos de ejecución (es decir, la pieza de código actúa sobre una entidad software tal como los hilos de ejecución) creados por el proceso hasta ese momento (cuyos identificadores se han guardado en la variable correspondiente descrita anteriormente) tanto tiempo como se haya calculado, mediante por ejemplo las funciones SuspendThread y Sleep de la librería kernel32.dll. Una vez transcurrido el periodo de tiempo calculado, se vuelven a activar los hilos de ejecución mediante por ejemplo la función ResumeThread de la librería kernel32.dll. A partir de ese instante se prosigue con la ejecución normal del proceso hasta la próxima vez que el proceso vuelve a llamar a la función de control (en la presente realización preferida, la función Present1).
Por lo tanto, cuando la pieza de código actúa sobre la entidad software referente a los hilos de ejecución, la pieza de código consigue controlar el uso que la aplicación (más concretamente, el juego), durante su ejecución, realiza de los recursos de hardware disponibles en el servidor de juegos.
De acuerdo con otra realización preferida de la invención, la pieza de código podría actuar también sobre otra entidad software tal como la memoria. En este caso, la pieza de código debería redireccionar todos aquellos servicios (por ejemplo, funciones y/o métodos) de las API destinados a gestionar la reserva de zonas de memoria, hacia servicios comprendidos en la propia pieza de código, de manera que estos servicios comprendidos en la pieza de código fueran capaces de asignar zonas de memoria a compartir por las diferentes instancias de un mismo juego. De este modo, las instancias en ejecución podrían compartir ciertas zonas de memoria, de manera que se reduciría considerablemente el uso de memoria por parte de estas instancias. Hay que tener en cuenta que, en determinados casos, habrá zonas de memoria exclusivas para cada instancia en ejecución, que no podrán ser compartidas (pueden contener, por ejemplo, datos relacionados con el usuario que ha solicitado la ejecución de la instancia). Por Por otro lado, la pieza de código también es capaz de gestionar otro tipo de entidad software tal como los cierres de exclusión mutua o candados (en inglés Locks), para conseguir que sea posible ejecutar más de una instancia de un mismo juego sobre el mismo servidor de juegos. Es muy normal en el mundo de los juegos de ordenador que los programadores incluyan cierres de exclusión mutua para evitar que un usuario pueda ejecutar más de una instancia del juego sobre el mismo sistema informático. Para ello, cuando se crea una primera instancia del juego, el cierre de exclusión mutua genera una etiqueta predeterminada asociada al juego (la etiqueta es única para cada juego), de manera que cuando el usuario intenta ejecutar una segunda instancia de un juego que se encuentra en ejecución, el cierre de exclusión mutua determina la existencia de una instancia en ejecución (a través de la existencia de la etiqueta) y no permite la ejecución de esta segunda instancia del juego.
imagen12
Para superar este inconveniente, la pieza de código que se inyecta en el proceso perteneciente al juego redirecciona los servicios de las API destinados a gestionar los cierres de exclusión mutua, hacia servicios correspondientes comprendidos en la propia pieza de código. De este modo, la pieza de código puede interceptar estos servicios y modificar la etiqueta predeterminada que le asigna el cierre de exclusión mutua, de manera que cuando se pretende ejecutar una segunda instancia del juego, el servicio no detecta ninguna instancia con la etiqueta predeterminada y se permite esta ejecución. Puesto que el proceso correspondiente a cada instancia en ejecución tiene inyectada la pieza de código, la etiqueta que se le asigna es diferente para cada instancia.
A pesar de que se ha descrito y representado una realización concreta de la presente invención, es evidente que el experto en la materia podrá introducir variantes y modificaciones, o sustituir los detalles por otros técnicamente equivalentes, sin apartarse del ámbito de protección definido por las reivindicaciones adjuntas.
A pesar también de que las realizaciones descritas de la invención con referencia a los dibujos comprenden sistemas de computación y procesos realizados en sistemas de computación, la invención también se extiende a programas de ordenador o a piezas de código ejecutable, más particularmente a programas de ordenador en o sobre unos medios portadores, adaptados para poner la invención en práctica. El programa de ordenador puede estar en forma de código fuente, de código objeto o en un código intermedio entre código fuente y código objeto, tal como en forma parcialmente compilada, o en cualquier otra forma adecuada para usar en la implementación de los procesos de acuerdo con la invención. El medio portador puede ser cualquier entidad o dispositivo capaz de portar el programa.
Por ejemplo, el medio portador puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM semiconductora, o un medio de grabación magnético, por ejemplo un floppy disc o un disco duro. Además, el medio portador puede ser un medio portador transmisible tal como una señal eléctrica u óptica que puede transmitirse vía cable eléctrico u óptico o mediante radio u otros medios.
Cuando el programa de ordenador está contenido en una señal que puede transmitirse directamente mediante un cable u otro dispositivo o medio, el medio portador puede estar constituido por dicho cable u otro dispositivo o medio.
Alternativamente, el medio portador puede ser un circuito integrado en el que está encapsulado (embedded) el programa de ordenador, estando adaptado dicho circuito integrado para realizar, o para usarse en la realización de, los procesos relevantes.

Claims (17)

  1. imagen1
    -Interceptar una llamada del proceso perteneciente a la aplicación a un servicio de la interfaz de programación de aplicaciones, cuya interceptación supone redireccionar un servicio de la interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código;
    -Actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones.
  2. 2. Procedimiento según la reivindicación 1, en el que el servicio de una interfaz de programación de aplicaciones es una función, y en el que redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código comprende:
    •
    Cargar en memoria la librería de enlace dinámico que comprende la función de la interfaz de programación de aplicaciones a redireccionar;
    •
    Sustituir, en la tabla de punteros a las funciones de la interfaz de programación de aplicaciones comprendidas en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena la función de la interfaz de programación de aplicaciones a redireccionar por la dirección de memoria inicial en la que se almacena la función correspondiente comprendida en la pieza de código.
  3. 3. Procedimiento según la reivindicación 2, en el que redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código comprende:
    • Almacenar en una primera variable la dirección de memoria inicial en la que se almacena la función de la interfaz de programación de aplicaciones a redireccionar.
  4. 4. Procedimiento según la reivindicación 1, en el que el servicio de una interfaz de programación de aplicaciones es un método de un objeto, y en el que redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código comprende:
    •
    Cargar en memoria la librería de enlace dinámico que comprende el método del objeto a redireccionar;
    •
    Verificar si el objeto asociado al método a redireccionar se crea por primera vez;
    •
    En caso de resultado positivo en la verificación,
    o Sustituir, en la tabla de punteros a los métodos del objeto comprendidos en la librería de enlace dinámico cargada, la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar, por la dirección de memoria inicial en la que se almacena el método correspondiente comprendido en la pieza de código.
  5. 5. Procedimiento según la reivindicación 4, en el que redireccionar un servicio de una interfaz de programación de aplicaciones hacia un servicio correspondiente comprendido en la pieza de código comprende:
    • Almacenar en una segunda variable la dirección de memoria inicial en la que se almacena el método del objeto a redireccionar.
  6. 6. Procedimiento según una cualquiera de las reivindicaciones 1 a 5, en el que el servicio de la interfaz de programación de aplicaciones es un servicio relacionado con la entidad software perteneciente al proceso, estando este servicio destinado a la creación de nuevos hilos de ejecución; en el que la entidad software es un hilo de ejecución; y en el que interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones comprende:
    •
    Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para generar un nuevo hilo de ejecución;
    •
    Generar un nuevo hilo de ejecución a partir del servicio correspondiente comprendido en la pieza de código;
    •
    Guardar el identificador del hilo de ejecución generado en una tercera variable que mantiene el registro de los hilos de ejecución creados.
    14
    imagen2
    generar un nuevo hilo de ejecución;
    •
    Realizar una llamada al servicio de la interfaz de programación de aplicaciones, a partir de la dirección de memoria inicial almacenada en la primera variable si el servicio es una función o en la segunda variable si el servicio es un método;
    •
    Recibir un identificador del nuevo hilo de ejecución generado por el servicio de la interfaz de programación de aplicaciones;
    •
    Guardar el identificador del hilo de ejecución generado en una tercera variable que mantiene el registro de los hilos de ejecución creados.
  7. 8. Procedimiento según una cualquiera de las reivindicaciones 6 ó 7, en el que actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones comprende:
    •
    Determinar un valor de rendimiento de la aplicación en ejecución;
    •
    Verificar si este valor de rendimiento de la aplicación supera un valor umbral;
    •
    En caso de resultado positivo, parar durante un tiempo predeterminado los hilos de ejecución, a partir de los identificadores almacenados en la tercera variable que mantiene el registro de los hilos de ejecución creados.
  8. 9. Procedimiento según la reivindicación 8, en el que determinar un valor de rendimiento de la aplicación en ejecución a partir del uso de recursos de hardware que realiza comprende:
    o Establecer como punto de control un servicio de una interfaz de programación de aplicaciones que el proceso, durante su ejecución, va a llamar iterativamente;
    o Determinar el tiempo transcurrido entre una primera llamada y una segunda llamada a este servicio, por parte del proceso;
    o Obtener un valor del rendimiento de la aplicación en ejecución a partir del tiempo determinado.
  9. 10. Procedimiento según una cualquiera de las reivindicaciones 1 a 5, en el que el servicio de la interfaz de programación de aplicaciones es un servicio relacionado con la entidad software correspondiente al proceso, estando este servicio destinado a la reserva de zonas de memoria; en el que la entidad software es una memoria; y en el que interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones comprende:
    • Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para reservar una zona de memoria.
  10. 11. Procedimiento según la reivindicación 10, en el que actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones comprende:
    • Reservar una zona de memoria compartida.
  11. 12. Procedimiento según una cualquiera de las reivindicaciones 1 a 5, en el que el servicio de la interfaz de programación de aplicaciones es un servicio relacionado con la entidad software correspondiente al proceso, estando este servicio destinado a intervenir sobre un cierre de exclusión mutua; en el que la entidad software es un cierre de exclusión mutua; y en el que interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones comprende:
    • Recibir una llamada del proceso al servicio correspondiente comprendido en la pieza de código, para intervenir sobre un cierre de exclusión mutua;
    15
    imagen3
    aplicación se ha iniciado en estado de suspensión, comprendiendo el procedimiento:
    -Reanudar la ejecución del proceso que se encuentra en estado de suspensión.
  12. 15.
    Pieza de código ejecutable que comprende instrucciones para ejecutar un procedimiento para controlar el uso de recursos de hardware de un sistema informático según una cualquiera de las reivindicaciones 1 a 14, estando esta pieza de código ejecutable adaptada para ser inyectada en un proceso perteneciente a una aplicación, cuando esta aplicación se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones y que se ejecuta sobre este sistema informático.
  13. 16.
    Pieza de código según la reivindicación 15, que está almacenado en unos medios de almacenamiento.
  14. 17.
    Pieza de código según la reivindicación 15, que es portado por una onda portadora.
  15. 18.
    Procedimiento para ejecutar una aplicación sobre el sistema operativo de un sistema informático, que comprende:
    -Iniciar la ejecución de un proceso asociado a la aplicación, en un estado de suspensión;
    -Inyectar la pieza de código ejecutable según una cualquiera de las reivindicaciones 15 a 17 en el proceso en estado de suspensión;
    -Ejecutar el procedimiento para controlar el uso de recursos de hardware de un sistema informático por parte de la aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones y que se ejecuta sobre este sistema informático, mediante la pieza de código ejecutable inyectada en el proceso, el procedimiento según una cualquiera de las reivindicaciones 1 a 14.
  16. 19. Sistema para controlar el uso de recursos de hardware de un sistema informático por parte de una aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones y que se ejecuta sobre este sistema informático, estando el sistema adaptado para ser inyectado en un proceso perteneciente a la aplicación, comprendiendo el sistema:
    -Medios informáticos para interceptar la llamada del proceso al servicio de la interfaz de programación de aplicaciones;
    -Medios informáticos para actuar sobre una entidad software perteneciente al proceso en ejecución, a partir de la interceptación de la llamada del proceso al servicio de la interfaz de programación de aplicaciones.
  17. 20. Sistema informático sobre el que se ejecuta una aplicación, que comprende una memoria y un procesador, que incorpora instrucciones almacenadas en la memoria y que son ejecutables por el procesador, comprendiendo las instrucciones funcionalidades para:
    -Iniciar la ejecución de un proceso asociado a la aplicación, en un estado de suspensión;
    -Inyectar la pieza de código ejecutable según una cualquiera de las reivindicaciones 15 a 17 en el proceso en estado de suspensión;
    -Ejecutar el procedimiento para controlar el uso de recursos de hardware de un sistema informático por parte de la aplicación que se ejecuta sobre un sistema operativo que comprende al menos una interfaz de programación de aplicaciones y que se ejecuta sobre este sistema informático, mediante la pieza de código ejecutable inyectada en el proceso, el procedimiento según una cualquiera de las reivindicaciones 1 a 14.
    16
ES201230580A 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático Active ES2439803B1 (es)

Priority Applications (10)

Application Number Priority Date Filing Date Title
ES201230580A ES2439803B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
JP2015506270A JP2015517159A (ja) 2012-04-19 2013-04-18 コンピュータ・システムのハードウエア資源の使用を制御する方法と、システムとピース・オブ・コード方法
DK13777888.2T DK2840496T3 (en) 2012-04-19 2013-04-18 PROCEDURE, SYSTEM AND EXECUTABLE CODE TO MANAGE THE USE OF HARDWARE RESOURCES OF A COMPUTER SYSTEM
US14/395,488 US9195505B2 (en) 2012-04-19 2013-04-18 Method, system and an executable piece of code for controlling the use of hardware resources of a computer system
PCT/ES2013/070248 WO2013156655A1 (es) 2012-04-19 2013-04-18 Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES13777888T ES2697681T3 (es) 2012-04-19 2013-04-18 Método, sistema y fragmento de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
HUE13777888A HUE041417T2 (hu) 2012-04-19 2013-04-18 Eljárás, rendszer és futtatható kód számítógépes rendszer hardver erõforrásai használatának vezérlésére
KR1020147032131A KR102057360B1 (ko) 2012-04-19 2013-04-18 컴퓨터 시스템의 하드웨어 자원 사용을 조정하기 위한 방법, 시스템 및 실행가능 프로그램 코드
EP13777888.2A EP2840496B1 (en) 2012-04-19 2013-04-18 Method, system and an executable piece of code for controlling the use of hardware resources of a computer system
CN201380031821.5A CN104364759B (zh) 2012-04-19 2013-04-18 用于控制计算机系统上硬件资源使用情况的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201230580A ES2439803B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático

Publications (2)

Publication Number Publication Date
ES2439803A1 ES2439803A1 (es) 2014-01-24
ES2439803B1 true ES2439803B1 (es) 2014-10-29

Family

ID=49382970

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201230580A Active ES2439803B1 (es) 2012-04-19 2012-04-19 Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES13777888T Active ES2697681T3 (es) 2012-04-19 2013-04-18 Método, sistema y fragmento de código ejecutable para controlar el uso de recursos de hardware de un sistema informático

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES13777888T Active ES2697681T3 (es) 2012-04-19 2013-04-18 Método, sistema y fragmento de código ejecutable para controlar el uso de recursos de hardware de un sistema informático

Country Status (9)

Country Link
US (1) US9195505B2 (es)
EP (1) EP2840496B1 (es)
JP (1) JP2015517159A (es)
KR (1) KR102057360B1 (es)
CN (1) CN104364759B (es)
DK (1) DK2840496T3 (es)
ES (2) ES2439803B1 (es)
HU (1) HUE041417T2 (es)
WO (1) WO2013156655A1 (es)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2439803B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES2439804B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
US20140113705A1 (en) 2012-10-19 2014-04-24 Nvidia Corporation Quick-resume gaming
RU2634173C1 (ru) * 2016-06-24 2017-10-24 Акционерное общество "Лаборатория Касперского" Система и способ обнаружения приложения удалённого администрирования
CN109597689B (zh) * 2018-12-10 2022-06-10 浪潮(北京)电子信息产业有限公司 一种分布式文件系统内存优化方法、装置、设备及介质
CN111381879B (zh) * 2018-12-31 2022-09-02 华为技术有限公司 一种数据处理方法及装置
US11250124B2 (en) * 2019-09-19 2022-02-15 Facebook Technologies, Llc Artificial reality system having hardware mutex with process authentication

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0546568A (ja) * 1991-08-08 1993-02-26 Internatl Business Mach Corp <Ibm> 分散アプリケーシヨン実行装置および方法
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
IL132916A (en) * 1999-11-14 2004-02-08 Mcafee Inc Method and system for intercepting an application program interface
GB0011020D0 (en) * 2000-05-09 2000-06-28 Ibm Intercepting system API calls
US7047337B2 (en) * 2003-04-24 2006-05-16 International Business Machines Corporation Concurrent access of shared resources utilizing tracking of request reception and completion order
US7380039B2 (en) 2003-12-30 2008-05-27 3Tera, Inc. Apparatus, method and system for aggregrating computing resources
US7653900B2 (en) * 2004-04-22 2010-01-26 Blue Coat Systems, Inc. System and method for remote application process control
USH2202H1 (en) 2004-04-28 2007-09-04 Symantec Corporation Method and apparatus to dynamically hook runtime processes without interrupting the flow of execution
US7725737B2 (en) * 2005-10-14 2010-05-25 Check Point Software Technologies, Inc. System and methodology providing secure workspace environment
US7788665B2 (en) * 2006-02-28 2010-08-31 Microsoft Corporation Migrating a virtual machine that owns a resource such as a hardware device
US8042122B2 (en) * 2007-06-27 2011-10-18 Microsoft Corporation Hybrid resource manager
US8255931B2 (en) * 2008-02-11 2012-08-28 Blue Coat Systems, Inc. Method for implementing ejection-safe API interception
US8650570B2 (en) * 2008-06-02 2014-02-11 Microsoft Corporation Method of assigning instructions in a process to a plurality of scheduler instances based on the instruction, in which each scheduler instance is allocated a set of negoitaited processor resources
US8683576B1 (en) * 2009-09-30 2014-03-25 Symantec Corporation Systems and methods for detecting a process to establish a backdoor connection with a computing device
ES2439803B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES2439804B1 (es) 2012-04-19 2014-10-29 Universitat Politècnica De Catalunya Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático

Also Published As

Publication number Publication date
CN104364759A (zh) 2015-02-18
EP2840496B1 (en) 2018-08-01
EP2840496A1 (en) 2015-02-25
WO2013156655A1 (es) 2013-10-24
DK2840496T3 (en) 2018-11-26
ES2697681T3 (es) 2019-01-25
HUE041417T2 (hu) 2019-05-28
JP2015517159A (ja) 2015-06-18
EP2840496A4 (en) 2015-12-16
KR20150004854A (ko) 2015-01-13
ES2439803A1 (es) 2014-01-24
US9195505B2 (en) 2015-11-24
CN104364759B (zh) 2017-10-27
US20150121402A1 (en) 2015-04-30
KR102057360B1 (ko) 2020-01-22

Similar Documents

Publication Publication Date Title
ES2439803B1 (es) Procedimiento, sistema y pieza de código ejecutable para controlar el uso de recursos de hardware de un sistema informático
ES2439804B1 (es) Procedimiento, sistema y pieza de código ejecutable para virtualizar un recurso de hardware asociado a un sistema informático
US8990538B2 (en) Managing memory with limited write cycles in heterogeneous memory systems
JP6652491B2 (ja) 目標メモリ・アドレスに対応するメモリ属性ユニットの領域を特定するための領域特定演算
ES2710887T3 (es) Utilización de palabras de dirección de datos indirectos de trasladador de datos asíncronos extendidos
ES2873229T3 (es) Motor de introspección de memoria para la protección de integridad de máquinas virtuales
US9081504B2 (en) Write bandwidth management for flash devices
US20120011500A1 (en) Managing a memory segment using a memory virtual appliance
BR112015022865B1 (pt) Método e aparelho para ativar seletivamente as operações de um monitor de máquina virtual sob demanda
US10061701B2 (en) Sharing of class data among virtual machine applications running on guests in virtualized environment using memory management facility
CN110532816B (zh) 存储器保护电路和存储器保护方法
US11899980B2 (en) Storage device including a turbo write buffer divided into a non-pinned buffer area and a pinned buffer area, an operation method of a storage system including the storage device in which data of the non-pinned and pinned buffer areas are flushed differently, and a host device controlling the storage device
CN112309450A (zh) 存储装置
CN113826072B (zh) 系统管理模式中的代码更新
KR102450838B1 (ko) 복수의 특권레벨에서 명령어들을 실행 가능한 데이터 처리장치에서의 성능 감시
TW201621678A (zh) 特權等級指出技術
US10073851B2 (en) Fast new file creation cache
US10776257B2 (en) Booting an application from multiple memories
CN106708619B (zh) 资源管理方法及装置
US20150143093A1 (en) Plurality of interface files usable for access to bios
US11074200B2 (en) Use-after-free exploit prevention architecture
KR20170019729A (ko) 전자 장치 및 이의 데이터 압축 방법
KR20150064653A (ko) 전자 장치 및 전자 장치에서의 메모리 할당 방법
ES2650174T3 (es) Procedimiento de gestión de una memoria de tarjeta electrónica

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2439803

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20141029