problemas con threads dentro de un componente
 

Amigos, estoy diseñando un componente visual que funciona como indicador. Dicho indicador alcanza su valor no directamente sinó simulando un movimiento que dura unos pocos segundos. Para que una aplicación que lo use pueda seguir funcionando mientras el control "se mueve" he puesto todo el código que simula el movimiento en un thread dentro del componente que se activa cuando el valor (a indicar) cambia y se suspende al llegar a dicho valor. El problema es que no logro que una aplicación con este componente siga funcionando mientras el control "se mueve". Todo se congela hasta que termine el movimiento como si no funcionara en hilos. ¿Tienen alguna idea de qué hice mal? Tratando de resumir, el esquema de código sería algo así:

procedure dibujar;
.....{dibuja todo el control y su escala en la posición requerida (dada por el "valor" temporal en el hilo), es un procedimiento público dentro de la unidad}

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}
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
Synchronize(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;

Si no se entiende puedo profundizar o hasta mandar un demo.

Hola, el código de primera vista parece estar bien.

Pero si decis que el programa se te congela, obviamente hay un problema.

Por lo que estuve mirando, me parece estar en el procedimiento mover;

un detalle que puede ser, pero no debería, es el valor del sleep muy pequeño, proba con valores mas grandes.

Lo que si genera mas sospechas es ciclo while que tenes dentro del mismo procedimiento. Pareciera que es el el que se dedica a actualizar la graficación del componente (ya que no indicas donde se hace). Si es asi, parece que no termina su ejecución hasta que termina de graficar, y ahi es el problema. Es como si estuvieras llamando al procedimiento mover directamente sin hilo.

Espero que te de una idea

Suerte

otros asuntos del mismo componente
 

Crandel, evidentemente somos casi vecinos, por lo menos en internet ya que soy de Montevideo. Sabés que finalmente hoy a la 0:30 de la madrugada pude solucionarlo poniendo un Application.processmessages antes del sleep en el procedimiento mover. Yo tenía uno pero lo ejecutaba solamente una vez por proceso de movimiento. Poniéndolo de esta forma procesa los mensajes cada vez que dibuja una instancia del control.

Sin embargo tal vez puedas ayudarme en esto. Ahora funciona a la perfección, pero solamente cuando está solo, ya que si pongo dos o más controles iguales de estos, en un mismo form, solo funciona el último. Los primeros ni siquiera terminan de dibujarse bien, quedan como colgados mientras el otro funciona perfecto. Tenés idea si existe alguna interacción prohibida entre los threads iguales o hay que poner alguna restricción en los componentes que usan threads.? Se me ocurre que como el hilo esta dentro del componente si hay dos queda todo igual y el procesador se hace algún lío con esto. Tal vez lo que digo sea un disparate pero aviso que hace 15 días no sabía lo que era un thread :-).

No hay ningún tipo de restricción en los holos de ls componentes. Cada componente ejecuta su propio hilo.

El problema que tenes es que estas poniendo Application.processmessages dentro del procedimiento mover y tu problema sigue siendo el mismo, tu componentes no esta corriendo multi hilo .

Con el processmessages, lo que le estas indicando a tu aplicación, es que procese los mensajes que tenga pendiente, pero eso no lo convierte en multihilo, dado que tu mientras los procesa, tu componente se deja de graficar. Sin embargo es una buena solución en muchas situaciones, pero no en la tuya.

Si queres mandame por mail tu código a crandel_z@yahoo.com.ar y te doy una mano.

Suerte

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.

;)

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

¿te parece que no?

Saludos.

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.

no entiendo esto del vcl con threads
 

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?

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.

"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.

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.

¿cuando dije semejante barbaridad? :confused: :confused:

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:

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

Claro, está usando las mismas variables.

Hasta luego.

;)

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

No tan poquitín, he visto... Tus correcciones funcionan "al pelo". Sin embargo el problema de la incompatibilidad de dos componentes de estos en el mismo form no lo pude solucionar. Por lo que pude detectar en el debugger, los extraños errores que me daba se deben a que durante el procedimiento "mover" le programa salta erráticamente de uno a otro hilo al cambiar de linea por lo que algunas variables del hilo toman diferentes valores según el componente ("miComp1" o "miComp2") al que pertenezcan en ese momento. Yo suponía que aunque fueran componentes iguales, no habría interacción entre un hilo y el otro, sin embargo parece que sí.

... Te creo. Cuando uno escribe el código para un componente, lo hace una sola vez, por lo que si uno pone dos componentes iguales en un form, siempre las variables de ambos van a ser las mismas. Es obvio que no te interpreto muy bien. Lo único que agrego es que las variables del thread dentro del componente supuestamente están definidas como privadas.

La pregunta sería, ¿como hacer para que un hilo dentro de un componente funcione "totalmente aislado" de los hilos equivalentes de componentes iguales?.

Estos no son saltos erráticos, ni son incorrectos, esto indica que perfectamente estan ejecutando su código en cada hilo.

no entiendo de donde sacas esta conclusión.
Cada hilo se ejecuta por separado, el código que se ejecuta obviamente será el mismo, pero los valores de cada uno de sus atributos depectera de cada uno, y no tienen porque ser iguales.

Entonces como harías para que los valores de variables de un componente no afecten los procedimientos del otro? Por ejemplo en mi caso, si suponemos que los dos componentes (iguales) deberían tomar valores diferentes al mismo tiempo, no entiendo como podrían hacerlo si los valores de las variables de fincionamiento de uno están afectando al otro y cambiando continuamente. Se de sobra por experiencia propia que no se puede trabajar cuando dos jefes piden cosas diferentes al mismo tiempo.

Hay una variable crítica del hilo (que es el "valor_final") que no puede estar afectada por un hilo de otro componente. Es como si le estuviéramos cambiando al procedimiento la orden de a donde debe dirigirse continuamente segun se esté ejecutando un componente o el otro. ¿No pueden estos dos hilos ("iguales" pertenecientes a componentes "distintos") funcionar aislados, o por lo menos sus variables no afectarse por las variables homónimas del otro? Supongo que sí pueden. ¿Pueden Uds decirme que me falta saber?. Aclaro que ni siquiera las variables definidas con "threadvar" funcionan independientemente de las del otro componente.

Lo que se ve parece ser: Dos componentes que acceden a UN ÚNICO set de variables (del hilo) al mismo tiempo. Por favor, sean claros que ya empiezo a sentir vergüenza de seguir preguntando.

Los componentes son clases, y como tales cada ves que creas uno se crea un nuevo objeto, por lo que cada uno posee su propio espacio de memoria.

Las respuestas son de acuerdo a las preguntas, si haces una pregunta generica, no esperes respuestas especificas para tu problema. :D

Saludos

Si fueran realmente independientes, no debería ir saltando de un componente a otro durante el debugger en UN método. Digámoslo así, Si ese método tiene definidas variables locales que se inicializan una vez (para c/componente), las variables de mayor jerarquía (las de la clase) no deberían cambiar su valor salvo que estemos hablando del otro hilo y por lo tanto que cambie todo el set (aún de variables locales). En mi caso sigue ejecutándose el mismo método (es decír linea por línea) pero cambia los valores de las variables privadas de la clase (porque ahora pertenecen al otro componente). Imaginate por ejemplo:

procedure xxx...
Var
a: Single;
begin
a := valor_final; {Según el Watch es el valor final del componente 1}
a := a - valor_final
{acá, p. ej, ya estamos en el otro thread (del componente 2 entonces este valor_final es diferente al de la linea anterior y el resultado ya no es cero aunque debería serlo...}
Yo sé que no debería pasar, pero es así.

Por lo de la especificidad, no lo tomes a mal Crandel, pero prefiero que me despidan por burro y no por indiscreto. De todas formas voy a ver si te puedo mandar algo de código más concreto, porque así me parece que no llegamos a nada.

Justamente si debe ir saltando durante el debugger. Porque el tiempo que lleva hasta que para, miras donde paro, miras el valor de las variables y le pedis que continue, el programa intenta de ejecutar el otro hilo.

Entonces si tenes dos componentes, y lo ejecutas paso a paso, debería mostrarte dos veces cada línea.

Los valores deberian ser coherentes, en cada hilo, es decir, por ejemplo una variable vale 1.3 en un hilo y 2.5 en el otro, cada vez que vuelve a cada hilo debería volver al valor que tenia (salvo que la hallas modificado).

que te despidan? no entendi.

aunque sea una versión simplificada del código para que podamos probar.

Otra idea. Si lo unico que te interesa es hacer que algo se mueva de forma incesante y repetitivamente, puedes crear un avi y ponerlo en un TAnimate, al estilo el copiar archivos de windows.

Suerte

mira lo que encontre por ahi.

capaz te pueda interesar

http://www.mit.jyu.fi/vesal/kurssit/...a/TimerBar.pas

usa un timer para mover la posición de un ProgressBar.

Suerte