Información sobre hilos de ejecución

[danielmj]

Hola Neftali,

Aver mira tengo esta unidad donde se ejecuta el thread:

Código Delphi [-]
unit unit2;

interface

uses SysUtils, Classes;

type
  Thilo = class(tThread)
  private
    procedure updatEdit;

  protected
    procedure Execute; override;
  end;

implementation

uses unit1;

//Thilo

procedure tHilo.execute;
begin
  synchronize(updatEdit);
end;

procedure tHilo.updatEdit;
var
  i: integer;

begin
  form1.progressBar1.max:= 1000000;
  for i:= 0 to form1.progressBar1.max -1 do
    form1.progressBar1.position:= i;
end;
end.

Por otra parte, en la llamada del button1 tengo esto:

Código Delphi [-]
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ComCtrls;

type
  TForm1 = class(TForm)
    ProgressBar1: TProgressBar;
    Button1: TButton;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation
uses unit2;

var
    FMiHilo: THilo;
{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  FMiHilo := THilo.Create(false);
end;

end.

Como ves el hilo lo hago en una unidad aparte de la del formulario, y siemplemente hago la llamada. El caso es que cuando se ejecuta, en un componente tEdit que he situado en el formulario para ver si podía escribir mientras trabajaba el bucle, sigo sin poder hacer nada. es decir que se ha "colgado" y no puedo hacer nada hasta que acaba. He intentado hacerlo como me indicabas, usando un procedimiento "independiente" sin controles visuales (salvo la barra de progreso). Entonces, ¿donde está mi error? ¿en que me estoy equivocando para que el edit quede bloqueado por el bucle?

Me he tomado la libertad de adjuntar el ejemplo que me he inventado digamos, para probar los hilos por si podeis echarle un vistazo y ver donde falla.

Un saludo.

[Neftali [Germán.Estévez]]

Es normal que no puedas escribir nada.

Tal y como te he comentado antes, lo que pones a ejecutar en el synchronize, es código que no se ejecuta en paralelo.
Para que me entiendas es algo así. Cuando llamas al synchronize, el thread detiene el programa original, ejecuta lo que hay dentro del synchronize y luego vuelve a el control al programa principal.

Por eso he comentado que en el synchronize hay que poner el mínimo código posible.

Según la explicación anterior, tú has hecho justo TODO lo contrario. Has colocado TODO el código del hilo en el synchronize. Por lo tanto tu hilo, tal y como está, no saca ningún provecho a las ventajas de ejecutar código en paralelo.

Cambia tu código por este, y aprecia las diferencias:

Código Delphi [-]
//Thilo
procedure tHilo.execute;
var
  i:integer;
begin

  // para inicializar el Max
  synchronize(updatEdit);

  for i := 0 to form1.progressBar1.max -1 do begin
    cont := i;
    synchronize(updatEdit);
 
    // para que te de tiempo a hacer algo....
    sleep(10);
  end;
end;

procedure tHilo.updatEdit;
begin
  form1.progressBar1.max:= 1000;
  form1.progressBar1.position:= cont;
end;

[danielmj]

Hola neftali, pues si que hay diferencia si, voy a seguir haciendo mas pruebas a ver si puedo sacarle partido a los hilos, la verdad es que... siendo filosofico (jaja) los hilos me resultan hirientemente útiles, lo de hirientes es por que o lo haces bien o a la menor oportunidad te darán la "patada"

Un saludo.

[danielmj]

Hola buenas de nuevo,

a ver segun entiendo, en un hilo no deben haber referencias a componentes visuales, pero en ese caso, si las operaciones de un procedimiento incluyen que se vaya mostrando información ¿como seria? ¿el hilo debería devolver el control a un procedimiento para "pintar" la informacion en una etiqueta (por ejemplo) y luego este procedimiento devolver el control al hilo para continuar? ¿eso sería así, pasandose el control de uno a otro hasta terminar? iba a poner un ejemplo real de la situación que tengo entre manos, pero son muchas lineas y no me deja, así que lo adjunto a este mensaje.

Tengo este procedimiento...

Código Delphi [-]
Procedure TPrincipal.Button1Click(Sender: TObject);
begin
  TrocearArchivo(labEdit1.Text,2048);
  button2.Enabled:= true;
end;

... que hace la llamada al procedimiento adjunto, ¿que parte del procedimiento debe estar fuera del hilo y cual dentro?

Un saludo y gracias.

[Neftali [Germán.Estévez]]

Empezado por danielmj

a ver segun entiendo, en un hilo no deben haber referencias a componentes visuales, pero en ese caso, si las operaciones de un procedimiento incluyen que se vaya mostrando información ¿como seria? ¿el hilo debería devolver el control a un procedimiento para "pintar" la informacion en una etiqueta (por ejemplo) y luego este procedimiento devolver el control al hilo para continuar? ¿eso sería así, pasandose el control de uno a otro hasta terminar? iba a poner un ejemplo real de la situación que tengo entre manos, pero son muchas lineas y no me deja, así que lo adjunto a este mensaje.

Tengo este procedimiento...

Código Delphi [-]
Procedure TPrincipal.Button1Click(Sender: TObject);
begin
  TrocearArchivo(labEdit1.Text,2048);
  button2.Enabled:= true;
end;

... que hace la llamada al procedimiento adjunto, ¿que parte del procedimiento debe estar fuera del hilo y cual dentro?

Un saludo y gracias.

Lo primero decir, que si no lees las cosas atentamente no llegaremos a ningún sitio, pues no nos vamos a entender...
Yo no he dicho que: "en un hilo no deben haber referencias a componentes visuales"

Mis palabras fueron las siguientes:

Eso se traduce en que desde dentro de un hilo no puedes acceder "alegremente" a componentes y código que tengas fuera de él..."
"Es decir, desde dentro del hilo, NO PUEDES llamar "directamente" a un botón del formulario (Form1.Button4.Enabled)...."
"...por lo tanto tenemos que asegurarnos que cuando accedemos desde el thread a "elementos externos" lo hagamos de forma exclusiva."

Creo que la diferencia es evidente.

SI se puede acceder a elementos externos como componentes, pero NO SE PUEDER HACER DIRECTAMENTE. Debes hacerlo utilizando Synchronize.

[Neftali [Germán.Estévez]]

Empezado por danielmj

pero en ese caso, si las operaciones de un procedimiento incluyen que se vaya mostrando información ¿como seria? ¿el hilo debería devolver el control a un procedimiento para "pintar" la informacion en una etiqueta (por ejemplo) y luego este procedimiento devolver el control al hilo para continuar? ¿eso sería así, pasandose el control de uno a otro hasta terminar?

SI.
Pero eso que parece tan complicado, se hace utilizando Synchonize de forma fácil.

[Neftali [Germán.Estévez]]

Empezado por danielmj

...así que lo adjunto a este mensaje.

Tengo este procedimiento...

Código Delphi [-]
Procedure TPrincipal.Button1Click(Sender: TObject);
begin
  TrocearArchivo(labEdit1.Text,2048);
  button2.Enabled:= true;
end;

... que hace la llamada al procedimiento adjunto, ¿que parte del procedimiento debe estar fuera del hilo y cual dentro?

Lo primero que hay que hacer es convertir ese "procedimiento", en un procedimiento "real"; Es decir, imagina que este procedimiento lo vas a llamar desde otro programa, donde no existen (porque se llaman diferente):
* principal.Memo1
* principal.LabEdit1
* principal.opc1.
* principal.Memo2
...

Estos elementos deberías estar como parámetros, porque en este procedimiento está "mezclando" lógica de negocio con temas visuales.

O te lo planteo de otra forma; Imagina que debes usar este procedimiento de TrocearArchivo llamándolo desde un programa que no tiene formularios.
¿Puedes hacerlo?

[danielmj]

Hola neftalí,

a ver contesto desde mi ignorancia, a tu pregunta... que yo sepa se puede llamar a un programa desde otro, por lo que deduzco que si un programa x está formado unicamente por un procedimiento sin formularios (en este momento estoy pensando en una aplicacion de consola), otro programa podrá invocarlo o llamarlo sin problemas, así que mi respuesta es si.

Un saludo.

[Ñuño Martínez]

El tema de los hilos es bastante complicado, ya que si dos hilos diferentes acceden al mismo tiempo al mismo dato puede haber problemas (por ejemplo que los dos intenten escribir a la vez, o que uno escriba y otro lea al mismo tiempo y por lo tanto los datos de quien lee estén corruptos por pillarlo a media escritura). Por ello hay que entender y usar los métodos y funciones de sincronización correctamente.

Respecto a la los componentes de la VCL, estos suelen ejecutarse en el llamado "hilo principal", por lo que otros hilos deben acceder a ellos de forma sincronizada.

[Neftali [Germán.Estévez]]

Empezado por danielmj

a ver contesto desde mi ignorancia, a tu pregunta... que yo sepa se puede llamar a un programa desde otro, por lo que deduzco que si un programa x está formado unicamente por un procedimiento sin formularios (en este momento estoy pensando en una aplicacion de consola), otro programa podrá invocarlo o llamarlo sin problemas, así que mi respuesta es si.

Me refería a tu procedimiento en concreto.
Crea un programa, con un formulario vacío y pon un botón que llame al procedimiento: TrocearArchivo(labEdit1.Text,2048)

¿Que pasará? Que falla en compilación porque el propio procedimiento hace referencia a controles visuales.
A eso me refería.
Esas referencias a objetos deberían estar como parámetros.