problemas con threads dentro de un componente

[jachguate]

El problema radica en el uso de synchronize que lo que hace es meterlo nuevamente todo al hilo principal de la VCL (via semaforos o un método equivalente). Te recomiendo leer la ayuda sobre este procedimiento para entender como funciona y en este caso dejar de usarlo, al menos donde lo usas, ya que probablemente sea necesario en todo o al menos en parte del método "dibujar".

Hasta luego.

[[Crandel]]

no creo que el problema sea el Synchronize, personalmente lo uso en un programa donde se actualiza un ProgressBar, dentro de un hilo.

[jachguate]

Empezado por Delphi help

Synchronize causes the call specified by Method to be executed using the main VCL thread, thereby avoiding multi-thread conflicts. If you are unsure whether a method call is thread-safe, call it from within the main VCL thread by passing it to the Synchronize method.

Execution of the thread is suspended while Method is executing in the main VCL thread.

¿te parece que no?

Saludos.

[[__hector]]

creo que en la instalacion de delphi viene un ejemplo de threads que muestra la eficiencia de diversos algoritmos de ordenacion (al menos venia en mi viejo delphi5) Es sencillo de analizar, y creo que se adapta bastante a lo que quieres lograr, asi que nada pierdes echandole un ojo.

[elcigarra]

jachguate, me parece que debes tener razón, el tema es que no entiendo el texto que enviaste de la ayuda (y no es porque no entienda inglés). Para más datos, el componente es una especie de progressbar y el código no es mucho más sobre Delphi que el esquema que mandé salvo que alguien quiera repasar sus lecciones de secundaria de movimiento armónico amortiguado, de Delphi no hay nada útil en el codigo (que lamento, crandel, no puedo mandartelo). Leete el esquema de mi primer mensaje. El metodo dibujar solamente dibuja una "foto" del control en las coordenadas del control, se me ocurre que el asunto es en el "mover" que es el lanzador del dibujo y es un método que no termina hasta alcanzar el valor final.

Mi idea inicial fue ponerlo TODO en un thread y esperaba que de esa forma si ponían dos componentes iguales funcionando en el mismo formulario, se verían moverse mismo tiempo (ya que cuando no utilizaba hilos, hasta que no terminaba uno no empezaba el otro). ¿Hay otra forma de lograr esto?.

Jachguate, ¿tu decís que no puedo utilizar synchronize en los VCL? ¿Cual es la alternativa entonces? Si tienes una variante a mi esquema tal vez pueda hacerlo funcionar. He visto ejemplos de VCL con threads pero en ningun caso se simulan movimientos continuos como en el mío.

Una última consecuencia curiosa, cuando pongo dos componentes de esos, no solamente se cualga uno de ellos. El segundo en actualizarse (que es el único que funciona) utiliza los valores de variables que pertenecen al primero. Es como que se le cruzan las variables del otro. ¿Alguna idea?

[S.M.S.]

El método synchronize sirve para sincronizar el hilo del proceso principal con el de tu Thread; esto es, el hilo del proceso principal llamará al procedimiento que hayamos indicado con synchronize, permitiéndole así acceder a datos de tu thread, aunque traerá también aparejado que durante ese tiempo los dos hilos estén haciendo esto y no otra cosa, por lo que, si ese trabajo es muy complicado, se puede producir ese efecto de congelación del que hablas.

No puedo ayudarte mucho con el código porque al ser un componente lo que estás desarrollando hago un poco aguas, pero creo que esto que te digo es lo que te ocurre con la instrucción synchronize (mover), ya que dentro del procedimiento mover tienes un ciclo que se repetirá mientras valortemporal <> valorfinal y, dentro de éste, una llamada al procedimiento dibuja y un sleep (20). Por si esto fuera poco, luego (dentro también del procedimiento mover) haces un mythread.suspend, lo que quiere decir que ordenas suspender la ejecución del hilo. Con todo esto parece estar claro que todo el trabajo se encarga al proceso principal y que tu Thread no pinta nada.

En cuanto al problema de acceso de un segundo componente a las variables del primero, puedo decirte que para que una variable pueda ser compartida por los diferentes metodos de un mismo hilo, pero inaccesible para otros hilos, se consigue declarándola con threadvar en lugar de var. Prueba con ello.

Saludos.

[elcigarra]

"El método synchronize sirve para sincronizar el hilo del proceso principal con el de tu Thread..." La pregunta es... no importa que el synchronize este lanzado desde "dentro" del thread (es decir desde el execute)???. Viste que el proceso principal solamente cambia el "Valor final" y manda el "Resume". Todo lo demás está en el código del thread. Ya probé poner incluso el procedimiento "Dibujar" como público dentro del thread pero es lo mismo.

Empiezo a sentir que me pongo denso con esto y estoy por vender mi PC y dedicarme a la carpintería... La pregunta oficial es: Como se hace para que dos componentes visuales (exigentes en la parte gráfica) operen en paralelo en una aplicación? En mi caso las variables de uso de la aplicación (es decir el valor del indicador) se llenan en el acto. El procedimiento mover (y el "dibujar" que éste lanza continuamente) es solamente un tema visual y sin ninguna importancia que no sea estética y que quiero que se ejecute "por atrás de todo" lo demás. ¿hay alternativas al synchronize?

Para simplificar, imaginen que tienen un componente (x ej. un indicador lineal tipo trackbar) que cuando cambias su variable "valor" se redibuja pixel por pixel con un sleep de unos pocos milisegundos hasta dicho valor. Como hacen para que si ponen dos, se muevan juntos y no uno después del otro? ¿es un thread la solución? Con un esquema me alcanzaría... si quieren un ejemplo de lo que quiero hacer (salvando las distancias) bajense el siguiente demo de uniworkstech en
http://www.uniworkstech.com/files/Demos/UniComponentsDemo.exe.
Si lo ven, todos estos se mueven juntos. No esperan que uno termine para empezar el otro.

[[Crandel]]

Definitivamente creo que tu problema es el ciclo while dentro del método mover.

Eliminalo y te va a funcionar.

La condición de salida agregala en tu ciclo Repeat junto con el Terminated.

Ese es el único problema

[jachguate]

Empezado por elcigarra

el tema es que no entiendo el texto que enviaste de la ayuda (y no es porque no entienda inglés).

Evidentemente aún te falta un poquitin por el lado de threads. Lo cierto es que synchronize sirve para evitar conflictos con el hilo principal de la VCL, y ejecuta el método que le envias mientras deja suspendido el hilo que lo llama. Por la forma en que haces las cosas, esto es equivalente a ejecutar todo en el hilo principal de la VCL (como si no fuese multihilos), pues siempre se está corriendo dentro de synchronize.

Empezado por elcigarra

Jachguate, ¿tu decís que no puedo utilizar synchronize en los VCL?

¿cuando dije semejante barbaridad?

Empezado por elcigarra

¿Cual es la alternativa entonces? Si tienes una variante a mi esquema tal vez pueda hacerlo funcionar.

Soy bastante rehacio a publicar trozos de código, pero esta vez por razones didácticas, he preparado esto, que estoy seguro funcionará mejor, aunque no creo que sea lo ideal:

procedure mythread.mover;
begin
  while not (valortemporal = valorfinal) do
  begin
  {con un algoritmo calculo valor temporal en función del tiempo
   transcurrido desde que se inició el movimiento, es decir:
   empieza en el valor viejo y termina en el nuevo}
    synchronize(dibujar);
    sleep(20); {esto hace que se redibuje cientos de veces
                todo el componente simulando el movimiento hasta llegar
                al valor}
  end;
  mythread.suspend; {hasta que el valor vuelva a cambiar}
end;

procedure mythread.execute
begin
  Repeat
    Mover;
  until Terminated;
end;

{y dentro del código del componente y fuera del hilo, para cuando cambia el valor}
procedure mycomponent.SetValor(Value: Single);
begin
  FValor:=Value;
  mythread.Resume;
end;

Empezado por elcigarra

He visto ejemplos de VCL con threads pero en ningun caso se simulan movimientos continuos como en el mío.

Que hay de la demo de threads que ya habia propuesto hector, los progressbar (o lo que sea que utilice) se "mueven" al mismo tiempo....

Empezado por elcigarra

El segundo en actualizarse (que es el único que funciona) utiliza los valores de variables que pertenecen al primero. Es como que se le cruzan las variables del otro. ¿Alguna idea?

Claro, está usando las mismas variables.

Hasta luego.