Alphasite

The programmers site

Estadísticas web

Estadisticas web

Publicidad

Languages

Google AdSense

Poll

Who's online

There are currently 0 users and 11 guests online.

Artículos, Delphi

Safeguards en Delphi.

Introducción


Los safeguards son el nombre que recibe un ingenioso mecanismo que nos permite, en cierto sentido, olvidarnos de los problemas asociados a liberar memoria en Delphi y que simulan de alguna forma el funcionamiento de un recolector de basura. En C++, para aquellos que han trabajado alguna vez con él, este mecanismo se conoce como Smart Pointers.

El truco

El truco para "olvidarnos" de liberar los objetos cuando terminamos con ellos consiste en el uso de interfaces. En delphi los interfaces incorporan un mecanismo de conteo referencial automático. Esto significa que cuando no se van a usar más (por ejemplo cuando salen de ámbito o cuando se "sobreescriben" y no quedan referencias al objeto que implementa dicho interface) se destruyen automáticamente.

Aplicaciones Multihilo en Delphi. Multihilo y el BDE

[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

procedure MiAccesoABD;
var
  qry : TQuery;
begin
  qry.DatabaseName := 'MiBaseDeDatos';
  qry.Sql.Add('SELECT * FROM Productos');
  qry.Open;
  .
  .  // Más código
  .
end;

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.

Delegados en Delphi. Pasando metodos y funciones como parametros.

Que es un delegado

Un delegado (de la palabra inglesa delegate) es un prototipo de función es decir, un esquema que debemos seguir al declarar una función. La palabra delegado proviene (o mejor dicho yo la escuche por primera vez) de C# y probablemente en delphi sería más conveniente referirse a ellas como tipos de funciones.

Los delegados se utilizan fundamentalmente para proporcionar tipado al paso de funciones como parametros a otras funciones o metodos.

Para que sirve un delegado

Si alguien ha programado alguna vez en C sabrá que pasar funciones como parametros esta a la orden del día, estas funciones suelen conocerse con el nombre de funciones de CallBack (algo así como "vuelveme a llamar") e implican que tu estás pasando una función como parametro que quieres que sea invocada cuando dicha función tenga unos ciertos datos preparados.

Una buena parte de las funciones de la API de windows funcionan de esta forma, por ejemplo si observamos la ayuda de la función EnumWindows de la API de windows (kernel32.dll):

La funcion EnumWindows enumera todas las ventans de alto nivel de la pantalla pasando el manejador de cada ventana a una funcion de callback definida por la aplicación. EnumWindows ejecuta hasta que la última ventana sea enumerada o hasta que la función de callback devuelva falso.

    BOOL EnumWindows(

    WNDENUMPROC lpEnumFunc,     // pointer to callback function
    LPARAM lParam       // application-defined value
   );

vemos que dicha función recibe dos parametros, uno de ellos siendo un puntero a una función de callback, es decir, una función que será invocada una vez por cada ventana que encuentre la función.

Aplicaciones Multihilo en Delphi. Primitivas de sincronización de Windows

[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).

Aplicaciones Multihilo en Delphi. Los problemas del multihilo

[series-info:left]

Introducción

En los dos artículos anteriores hemos visto una pequeña introducción a la programación multihilo en delphi así como a las funciones de sincronización que Delphi proprociona. Estas funciones de sincronización y el mero hecho de programar usando varios hilos tiene aparejados una serie de problemas a los que deberemos hacer frente si queremos que nuestra aplicación funcione correctamente y sin problemas.

Condición de carrera y exclusión mútua

Una condición de carrera es una situación indeseable en programación y que consiste en que el correcto funcionamiento del programa (o de un segmento del código del programa) depende del orden de ejecución de las tareas.

El problema principal de las condiciones de carrera es que son dificiles de identificar y encontrar y, dado que dos ejecuciones de un mismo programa pueden tener dos planificaciones completamente distintas para sus hilos, muy dificiles de reproducir.

El uso de primitivas de sincronización para todos los datos compartidos nos ha permitido en todo momento evitar situaciones como la siguiente:

Aplicaciones Multihilo en Delphi: Metodos de sincronización de Delphi

[series-info:center]

Introducción

Probablemente la parte más compleja al programar una aplicación con varios hilos es la sincronización entre estos tanto en el acceso a los datos compartidos como en el correcto orden de ejecución que deben seguir.

Uno de los problemas de desarrollar una aplicación multihilo es que son bastante dificiles de depurar puesto que los hilos van entrando y saliendo de ejecución conforme se va acabando su tiempo de ejecución de forma que, al depurar, el depurador va saltando de una linea de código a otra dependiendo de la tarea que vaya estando en la CPU así que siempre hay que tener mucho cuidado al escribir el código por que, si vas a tener que depurarlo, vas a pasarte un buen rato en ello (por no hablar del hecho de que los hilos no tienen porqué, y probablemente no lo haga, ejecutar en el mismo orden y con los mismos tiempos en dos ejecuciones consecutivas).

En esta parte trataremos los objetos de sincronismo más importante que proporciona Delphi mientras que en el siguiente nos centraremos en las primitivas de sincronización que proporciona la API de windows.

Aplicaciones Multihilo en Delphi: TThread y Sincronización Básica

[series-info:center]

Introducción

Si no lo has leido ya, y eres relativamente nuevo al mundo de la programación multihilo es recomendable empezar leyendo este otro artículo para poder decidir correctamente si realmente es necesario implementar un sistema multihilo o no.

Definiendo nuestro hilo

Delphi facilita mucho la creación de hilos de ejecución proporcionando una clase base que podemos heredar para definir nuestras tareas de ejecución. Esta clase es la clase TThread.

Un ejemplo de una aplicación que usa una tarea para comprimir un archivo.

{ Heredamos la clase TThread y definimos lo que queremos que
el hilo haga haciendo un override del metodo Execute }
type TMiThread = class(TThread)
private
FFileName : String;
public
{ El constructor de la clase
CreateSuspended : Si la tarea se crea suspendida

Un vistazo al .dpr

Cuando creamos un projecto nuevo en Delphi el IDE automáticamente crea un archivo con extensión dpr (delphi project) y, si el proyecto contiene forms, un archivo dfm (delphi form) por cada form del proyecto (y también una unidad .pas por cada uno).

El archivo con extensión dpr constituye un archivo de proyecto de Delphi. En el se encuentra recogido el código de inicialización de la aplicación así como todas las unidades y formularios del proyecto.

Delphi esta construido sobre el lenguaje de programación pascal, o más concretamente sobre Object Pascal que incluye el paradigma de objetos al lenguaje Pascal. Por ello conserva la organización inicial de pascal en casi su totalidad.

Delphi Static Classes (Singleton Pattern)

When your day work involves programming in Delphi and you have programmed in a language such as C++ or C# which allow static class you sometimes miss them as they are an useful resource.

What's a static class

A static class is, simply put, a class that provides some methods, properties and even fields but which doesn't need an instance to be used, that is, you don't need to create an instance of the class in order to call its methods or access its properties.

Actually, in C# for example, this separation reach the method, field and property level, that is, it is possible to define some methods to be static while other ones are not, and so such methods may be called without having to instantiate the class. In C# that looks more or less like this:

public class MyStaticClass
{
  private int m_value;

  public MyStaticClass()
  {
    m_value = 0;
  }

  public int Value(){ return m_value; }

  public static int ModDivision(int numerator, int denominator)
  {
    int result = numerator;
    while (result < denominator)
    {
      result = result - denominator;
    }
    return result;
  }
}