problemas con threads dentro de un componente

[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

[elcigarra]

Empezado por jachguate

Evidentemente aún te falta un poquitin por el lado de threads.

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

Empezado por jachguate

Claro, está usando las mismas variables.

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

[[Crandel]]

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.

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

Yo suponía que aunque fueran componentes iguales, no habría interacción entre un hilo y el otro, sin embargo parece que sí.

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.

[elcigarra]

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.

[[Crandel]]

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.

Saludos

[elcigarra]

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.