Antes de empezar

Como indiqué en la parte final del artículo anterior este artículo se ha retrasado tanto que he decidido sacar el código antes de estar acabado. Pese a que la parte fundamental del código es correcta, sobre todo a los efectos de ilustrar este artículo, no debe considerarse en producción y no recomiendo utilizarla para su uso en ninguna aplicación "real", al menos hasta que publique la versión completa.

La web del proyecto y su licencia

El código y otra información adicional está disponible en la página del proyecto Monet Plugins Library y tenéis disponible la última versión del código en el control de versiones de subversion http://svn.thealphasite.org/Monet.

Introducción

Una de las posibilidades que incluye .NET es el uso de atributos para proporcionar metainformación añadida a las distintas partes del código que creamos.

Los atributos de .NET nos proporcionan una poderosa herramienta para añadir información a nuestras clases, métodos, propiedades etc.

Un atributo puede aplicarse puede aplicarse sobre cualquier elemento básico de .NET es decir, clases, eventos, propiedades, métodos, etc y añadirá información a dicho elemento que posteriormente podremos consultar en tiempo de diseño, compilación o ejecución.

Aspect Oriented Programming (Programación orientada a aspectos)

El uso de atributos nos permite acercar la programación en .NET al concepto de AOP, que son las siglas inglesas de Aspect Oriented Programing o Programación arientada a aspectos.

Para comprender correctamente en que consiste el paradigma de programación orientada a aspectos debemos partir de la base de las limitaciones de la programación orientada a objetos. En el paradigma orientado a objetos, el concepto de herencia describe las relaciones jerárquicas entre los distintos objetos que a su vez modelan el mundo real (o conceptos de este).

[series-info:left]

Introducción

Uno de los problemas del multihilo en Delphi se da a la hora de acceder a la base de datos. En Delphi no podemos sencillamente ejecutar el siguiente código desde una tarea por que, probablemente, nos de un error en tiempo de ejecución

Sesiones de base de datos

Esto es debido a que el motor de base de datos (el BDE) no soporta llamadas concurrentes en la misma sesion de la base de datos. Esto quiere decir que, aunque podemos tener tan solo un TDatabase, debemos tener una sola sesion por cada hilo que acceda a la base de datos.

[series-info:left]

Introducción

En las anteriores partes, en los dos primeros articulos, hemos visto como crear y sincronizar hilos usando las clases predefinidas de Delphi. Estas clases son en realidad un encapsulamiento de las primitivas que nos proporciona windows para el control de hilos de ejecución pero hay determinadas cosas que no se pueden hacer con ellas y debemos recurrir directamente a los servicios que nos proporciona el sistema operativo.

Primitivas de sincronización de Windows

Handles

Las funciones de creación de objetos de windows son bastante similares entre si y tienen la "peculiaridad" de no devolver una instancia del objeto tal y como podemos estar acostumbrados en Delphi sino que devuelve siempre un THandle que no es ni más ni menos que un cardinal. Este cardinal es en realidad el identificador que tiene windows para el objeto que ha creado internamente y que el mismo mantiene.

De esta forma, para aquellos elementos con nombre, podemos acceder a ellos desde cualquier proceso que este ejecutando (no solamente desde los hilos del proceso que lo crea) siempre y cuando tengamos los permisos suficientes (por ejemplo un proceso ejecutando bajo el identificador de un usuario de windows tendrá limitaciones a la hora de acceder a un objeto creado por un administrador).

Introducción

Este artículo sirve de introducción al concepto de espacio de memoria de un proceso para su aplicación al concepto de multihilo de forma que solo da una introducción a los distintos segmentos de memoria y a aspectos como la visibilidad para centrarse en el porque y el cuando de la sincronización en el acceso a datos.

En la mayoría de los sistemas operativos (y para lo que nos ocupa en Windows y en Linux) todo proceso tiene varios segmentos en memoria, en concreto son el segmento de código, el segmento de datos, el segmento de pila y el segmento de heap.

Introduction

First thing we have to keep in mind when we try to get the CPU load for windows processes is the fact that Windows isn't magically calculating that percentage.

In fact, instead of maintaining a percentage that wouldn't be useful, Windows, keeps track, for each process, of the time that the process has been executing on user mode, the time it has been executing in kernel mode and the instant the process was created.

With all that data we can't just obtain the instant CPU load for a process. We can get the average CPU load for the process by a simple arithmetic calculation (AvgTime = User Time + Kernel Time / Actual Time - Creation Time). We could say that instantaneous CPU load value doesn't exist, just like Electric Potential :D

Keep reading ... ;)