Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   C++ Builder (https://www.clubdelphi.com/foros/forumdisplay.php?f=13)
-   -   problema con thread (https://www.clubdelphi.com/foros/showthread.php?t=55652)

pulpin 23-04-2008 07:53:55
problema con thread
 
amigos una ves mas recurro a su ayuda, lo que sucede es que dentro de mi programa se lleva acabo un retardo necesario para el funcionamiento del mismo, pero bueno este retardo que en si esta da do por una funcion del tipo
WaitForSingleObject detiene el resto de mi programa impidiendo que en este se lleven acabo otras funciones como oprimir un boton, el retardo es de unos 3 segundos, aca mi pregunta: como puedo evitar que este retardo dentro de el hilo detenga la ejecucion del resto de mi programa, de antemano muchas gracias?:confused:

escafandra 23-04-2008 13:11:31
¿Estás obligado a usar WaitForSingleObject?, Existen otras formas de esperar a que termine un thread sin un bloqueo total de la aplicación.

Código:
// Declaras una variable de la clase bool Terminado, porque Terminated no es accesible desde fuera. Le asignas true en el thread al terminar.

for(;!MyThread->Terminado;){
    Application->ProcessMessages();
}
La aplicación espera a que el thread termine pero no se bloquea.

Saludos.

luiggixD 23-04-2008 15:33:28
Esa funcion la estas llamando desde un hilo o la usas en medio de tu aplicacion? Yo creo que no estas empleando hilos, y lo que dice escafandra es inconsistente por el concepto de los hilos. Cuando creas un hilo, en su funcion Execute() debes hacer algo asi:

Código:
void __fastcall TUnThread::Execute()
{
  //algun codigo si es q lo necesitas
  while(!Terminated) // agregas mas casos en los que puede terminar tu hilo
  {
  //codigo de lo que hace tu hilo
  }
  //si necesitas que se haga algo mas antes que el hilo termine
}
En caso que no estes usando hilos en tu aplicacion, esta re va a detener cuando llames a la funcion que propones si la llamas desde el Form. Si llamas a la funcion desde un hilo, tu aplicacion funcionara correctamente.

Una nota ultima, el Application->ProcessMessages(); no es una mala idea pero de todas maneras no es una buena practica. Lo mas recomendable (aunque un poco complicado) es emplear hilos.

Espero que te ayude

Luiggi

escafandra 23-04-2008 17:10:48
luiggixD, Perdona pero no me parece inconsistente, de hecho lo utilizo para esperar a la terminación de un thread en un programa que estoy escribiendo y que debe esperar, solo que no uso WaitForSingleObject, que congela toda la aplicación, sino el sistema que he descrito. Es posible que no me explicase bien, de forma que amplio un poco tu código de ejemplo añadiendo mi idea:


Código:
void __fastcall TUnThread::Execute()
{
  Treminado = false; // Variable que añadimos como miembro a TUnThread


  //algun codigo si es q lo necesitas
  while(!Terminated) // agregas mas casos en los que puede terminar tu hilo
  {
  //codigo de lo que hace tu hilo
  }
  //si necesitas que se haga algo mas antes que el hilo termine



  Terminado = true; // Variable que añadimos como miembro a TUnThread
}
En la aplicación Codigo de espera a la terminación del thread:

Código:
Form1::Funcion(){
// Creamos el Thread y comienza la ejecución
.
.
.
// Ahora necesito esperar....
for(;!TUnThread->Terminado;){
    Application->ProcessMessages();  // Permite procesar mensajes y evitar la "congelación total" de la aplicación.
}
.
.
.
}
Durante la espera se pueden procesar mensajes y por lo tanto otros eventos, sólo se bloquea el código de la función que está esperando.


Saludos.

luiggixD 23-04-2008 17:34:09
En teoria el hilo no debe detener a la aplicacion. Si dentro del hilo realizas operaciones que interactuan con el Form o con cualquier otra parte de tu aplicacion, lo mejor seria sincronizar(funcion_form), donde funcion_form es una funcion que defines dentro del hilo que encapsula todas las interacciones con el form, ahora puedes elaborar muchas mas funciones. El hilo no deberia detener al programa, y asi no empleas el Application->ProcessMessages();

me deje entender??

me parece raro que se congele tu programa empleando hilos XD! quizas en tu misma aplicacion estes haciendo algo que la retrase

pulpin 23-04-2008 17:57:10
muchas gracias a ambos por su ayuda, pero creo que yo me he equivocado ya que siento que no me he explicado bien, cuando le doy "imag->Resume();"
el hilo inicia, en ese momento mi hilo llama a una funcion invocada desde una dll (de la cual tengo el codigo fuente) esta funcion esta definida en el programa principal y no en el hilo, la funcion usa un WaitForSingleObject, esta funcio detiene por completo mi programa tanto el hilo "que es el que se debe detener por este tiempo", y el resto de la aplicacion en la cual no puede ni presionar otro boton. espero les sea mas claro, gracias amigos.:D

luiggixD 23-04-2008 18:09:21
podrias detener el hilo con la funcion Suspend() y luego le haces un Reume()

escafandra 23-04-2008 18:20:12
Cita:
Empezado por luiggixD (Mensaje 281984)
En teoria el hilo no debe detener a la aplicacion. Si dentro del hilo realizas operaciones que interactuan con el Form o con cualquier otra parte de tu aplicacion, lo mejor seria sincronizar(funcion_form), donde funcion_form es una funcion que defines dentro del hilo que encapsula todas las interacciones con el form, ahora puedes elaborar muchas mas funciones. El hilo no deberia detener al programa, y asi no empleas el Application->ProcessMessages();

me deje entender??

me parece raro que se congele tu programa empleando hilos XD! quizas en tu misma aplicacion estes haciendo algo que la retrase
..Si, tienes razón, el hilo no debe ni detiene la aplicación, la que lo detiene es la función WaitForSingleObject hasta que termina el hilo que se le pasa como parámetro (Handle).

El hilo debe interactuar con Synchronize con el form. Pero imagina que parte del código no puede seguir sin conocer un resultado. Y que ese resultado va a tardar en saberse. Entonces te puede interesar colocar en un hilo el código que sabes que va a tardar y por lo tanto semibloquear la aplicación unos segundos. ¿Y la espera...? Si la espera la haces con WaitForSingleObject, entonces es un desastre...

Con el sistema que propongo, la aplicación no espera nada, los eventos siguen ocurriendo, lo único que espera es el código que mantiene el bucle descrito.

Te preguntarás: Si al final usas ProcessMessages(), ¿Entonces porqué programar un hilo?. Pues para que las llamadas a ProcessMessages() no se interrumpan por la tarea que más tarde, por ejemplo una conexión a internet o llamada a procesos API que obligan a esperar...

Como pulpin ha hecho la pregunta, he dado por hecho que estaba ante una situación como la que describo y por eso le propongo esto. Evidentemente es sólo para estos casos especiales de describo.

De todas formas pulpin ha resuelto su problema.


Saludos.;)

pulpin 23-04-2008 18:27:50
no porque mi hilo esta en ejecucion y la funcion necesariamente se tiene que detener durante ese tiempo mientras le llegan otros datos, cuando espera el rsto de mi programa deberia estar en funcionamiento normal.

cuando recibe los datos el hilo sigue su funcionamiento normalmente.

eje:

Form
{
codigo form incluyendo botones y demas;
invoco la funcion recibo datos(desde una dll);
}
inicio de hebra
{
recibo datos(estafuncion contiene el wait.....); //aqui es donde se para //todo mi programa por 3 segundos, cada que pasa por este sitio, y solo //deberia parar en el hilo.
}

espero ser mas ilustrativo:p

escafandra 23-04-2008 18:54:50
El problema es que WaitForSingleObject para todo. Lo que no entiendo es si la llamas tú o si lo hace la dll. Si la llamas tú, sabrás cual es el proceso que esperas que termine... No debería llamarse desde un hilo pues deja de tener sentido ese hilo.

Si puedes:

Código:
función(...)
{
  .
  .
  // Necesito datos.
  Abro hilo que me da datos
 
  //espero datos. Mi aplicación no se detendrá, pero si esta función.
  for(;hilo->Terminado==false;) Application->ProcessMessages();
 
  // Ya tengo los datos y sigo con la función
  .
  .
}

¿Te sirve?

Saludos.

pulpin 23-04-2008 19:00:45
pues escafranda desafortunadamente no puedo escaparme del waitforsingleobject ya que este esta dentro del codigo de la dll y es necesario .

:(

escafandra 23-04-2008 19:15:28
Mala cosa. Revisa esto, aunque posiblemente lo has hecho.

Dices que tienes el código fuente de esa dll.... Podrias modificarla y recompilarla. Sólo es una idea aunque posiblemente la peor.

Saludos.


EDITO:

Mira WaitForMultipleObjects también por si te sirve.

pulpin 25-04-2008 07:08:15
igualmente gracias por tu ayuda escafranda, voy a ver como puedo resolver este inconveniente, espero no se me salga de las manos.

post: tu siempre salvandome de tanto enredo, ya te debo como 5.:p

pulpin 07-05-2008 03:36:36
aun sigo en problemas
 
bueno estube investigando, sobre waitformultipleobjects, y segun lo que lei si utilizo esta funcion puedo evitar que los demas hilos se interrunmpan, estoy en lo correcto o no puedo usarlo para este motivo, espero tu opinion?;)

por ultimo alguna idea de como hacer el cambio.

escafandra 07-05-2008 08:23:42
Bueno, por lo que dices, te debes haber decidido por recompilar la dll. En principio lo fácil sería hacer ese cambio que apuntas. Cambiar la función
DWORD WINAPI WaitForSingleObject(
__in HANDLE hHandle,
__in DWORD dwMilliseconds
);[FONT=verdana,geneva,lucida,'lucida grande',arial,helvetica,sans-serif]

por:

[/font]DWORD WINAPI WaitForMultipleObjects(
__in DWORD nCount,
__in const HANDLE* lpHandles,
__in BOOL bWaitAll,
__in DWORD dwMilliseconds
);

La diferencia es que el hilo lo debes pasar como una matriz de hilos, es decir un puntero al handle en cuestión. En nCount pones 1 (un sólo hilo). En este caso bWaitAll no tiene mucho sentido, colócalo en true.

Por último aquí tienes más información: WaitForSingleObject y WaitForMultipleObjects

Saludos.

pulpin 07-05-2008 21:52:44
estube pensando en otra solucion sin modificar el dll.
bueno segun lei en internet es posible evitar este inconveniente si dentro del hilo seda el waitforobject, el codigo de la funcion principal se seguiria procesando normalmente. pero al ensayar tube un inconveniente que no se como buscar, mi programa es:

Form1-> "el cual es el que inicia normalmente, donde se cargan todas las funciones donde se inicia todo mi programa y el qye normalmente esta pendiente de los botonoes y demas metodos."

Form2->" en el cual se desprende una pequeña ventana en la cual puedes editar una imagen que se encuantra en el Form1 para luego imprimirla."

Form3->" y el ultimo y mas doloroso, un objeto thread en el cual lo que hago es llamar metodo void Del form1 , en la cual se lleva acabo una graficacion y recepcion de datos de un microcontrolador"

lo que quiero es hacer la recepcion de datos dentro del hilo ya que la recepcion es la que detiene el proceso esta contiene el waitforobject, luego de recibir los datos me voy para el void del form1 y grafico y luego vuelvo para la siguiente recepcion. sera que asi me funciona?

lo que no me ha dejado llevar acabo mi plan es uqe la funcion que recibe los datos esta definida de la siguiente forma:

DWORD SendReceivePacket(BYTE *SendData, DWORD SendLength, BYTE *ReceiveData,DWORD *ReceiveLength, UINT SendDelay, UINT ReceiveDelay);
// definida en el form1

mi preguntas es como puedo llamar esta funcion desde la hebra "form3"?

gracias, espero tu opinion.:)

escafandra 08-05-2008 00:06:35
Bueno... Para usar elementos de la VCL en un thread, deba asegurarse la seguridad, valga la redundancia. Debes revisar el método Synchronize. Y creo que debes hacerlo así pues quieres llamas a una función de una clase de Form1 a la que no pertenece tu thread. Cualquier modificación en objetos VCL debe llevarse a cabo de esta manera.

En la ayuda de Builder tienes un ejemplo demostrativo de como usar Synchronize.

Saludos.

pulpin 08-05-2008 06:05:55
bueno depronto creo que me e vuelto a enredar un poco, lo que necesito desde mi thread (hilo.cpp) es llamar a una funcion que se encuentra en el proceso principal (osciloscopio.cpp) una funcion definida como DWORD (as,jj,sfd,kjh);

normalmente puedo llamar funciones y demas asi: Form1->Button1->click();
pero esta funcion no la he podido llamar, la verdad e tratado de muchas formas de hacerlo pero no he hallado la forma, y en internet no logro allar informacion de este tipo de funcion.
espero ser mas claro.:rolleyes:

escafandra 08-05-2008 08:09:37
Pues como te indiqué, con el método Synchronize:

Código:
#include "Unit1.h"  // la del Form1...

//-------------------------------------------
MiThread::Button1Click()
{
  Form1->Button1->click();  // Llamas a tu función delde un método del thread
}

//-------------------------------------------
MiThread::OtraFuncion()
{
  Form1->SendReceivePacket(....);  // Llamas a tu función delde un método del thread
}


MiThread::Execute()
{
.
.
.
  Synchronize(Button1Click); // Aquí utilizas tu llamada CUANDO TE INTERESE...
  Synchronize(OtraFuncion); // Aquí llamas otro funcion.....CUANDO TE INTERESE...
.
.
.

}
¿Complicado?... Bueno, no tanto, pero desde un thread debe ser asi...

Saludos.

pulpin 09-05-2008 07:03:25
bueno, la cosa no va como quiero, la verdad sigue igual, he incorporado dos soluciones siguiendo tus pasos y el consejo visto en la red pero o lo he hecho mal o no funciona.

en la primera llamo la funcion desde el hilo, y todo bien hasta que mi funcion invoca la funcion de la dll y esta a su ves procesa el waitforobject, donde todo se detiene.

en la segunda, hago una "transaccion" defino las funciones en el hilo, y para usarlas en el form1, las llamo form3->sendreceivetpacket();, en cierta forma evito que el hilo procese algo en el form1(creo), pero aun asi el proceso se relentiza cuando en la dll se da el waitforobject.

la verdad ya no se que hacer, voy a tratar pasando todo lo que tiene que ver con la comunicacion (inicializacion de dll, inicio de comunicacion definiendo endpoints,etc) a ver si asi no se detiene. y si no tendre que dejar de esa forma mi tesis.

bueno espero que puedas darme algun consejo u idea que tengas, y antes de que se me olvide disculpa por tanto enredo en algunos casos, ya que soy 90% empirico en c++.

gracias.:(

escafandra 09-05-2008 08:26:02
Pienso que el problema sigue estando en esa dll. Si llamas a funciones de esa dll desde tu hilo, y se encuentra con un WaitForSingleObject... Se detiene.

Sigo pensando que si tienes las fuentes de la dll, la modifiques y recompiles...
Quizas puedas probar una solución un poco menos drástica. Sobrecarga sólo la función de la dll que te da problemas. Para eso, crea un archivo cpp con la función y la incluyes en el archivo cpp donde la uses o en la del form1. En esa sobrecarga puedes intentar el cambio WaitForSingleObject por WaitForMultipleObjects tal como comentábamos hace unos posts. O utilizando la primera técnica que te comenté para esperar (pero entonces deberás crear otro hilo mas que se llame desde tu hilo...)

Código:
# include "archivo.cpp"
Esta técnica la he utilizado para corregir algún bug del mismo Builder y me ha funcionado bien. Recompilar toda la dll es mas trabajoso pero evitará que estés pendiente de esa "sobrecarga" en cada aplicación nueva.

Por último decirte que esto que te pasa no tiene que ver con Builder ni C++ sino con Windows, WaitForSingleObject es de la API de Windows.

pulpin 09-05-2008 08:46:10
creo que eso de modificar a waitformultipleobjects, es mas compleajo porque cuando trate de hacerlo me salia un error que no entendia, ya que lo hice a la rapida, "cambio, pongo los parametros basicos y listo", pues no entiendo eso, pero bueno, en este momento estoy tratando de llevar al hilo todo lo de la comunicacion, pero tengo un problema creo que no es dificil pero no se que hacer, desde el hilo estoy llamando objetos ->

Form1->RadioButton2->Checkked=true;

todo compila bien pero cuando el sistema trata de procesar esa linea para el proceso y muestra un error de "violacion de acceso a memoria en form1.cpp....."
cuando llamo desde form1 que es donde incluyo=

#include "hilo.cpp"

tod me sale bien pero a la inversa no.
que puedo hacer?

y por ultimo luego de ensayar de esta forma me pondre a hacer lo que me dices de crear otro hilo y cargarlo desde mi primer hilo a ver que sucede.

Espero no perder la esperanza ya que es lo ultimo que me falta para terminar.

escafandra 09-05-2008 09:46:42
Insisto que para llamar desde el hilo a funciones o usar propiedades de Form1, debes utilizar Synchronize.

Código:

#include "Unit1.h"  // la del Form1...

//-------------------------------------------
MiThread::Funcion()
{
 Form1->RadioButton2->Checkked=true;
}

MiThread::Execute()
{
.
.
  Synchronize(Funcion);
.
.

}
Saludos.

pulpin 09-05-2008 16:28:19
si ya estoy usando la funcion de sincronizacion, exactamente igual que en el post, dentro de la funcion que estoy sincronizando, invoco objetos del form1 pero me salen los errores que te mencio, si incluyo form1.cpp, en hilo.cpp me sale un error de doble declaracion de parametros.

escafandra 09-05-2008 16:57:44
No debes incluir Form1.cpp sino la cabecera.

#include Form1.h

Saludos.

pulpin 09-05-2008 17:25:38
esta ya la tengo incluida,la cabecera del form1.h y aun asi sale ese error.

como te digo compila bien pero cuando ejecuto y entra a procesar = (ejemplo)

Form1->RadioButton2->Checked=true;

me detiene el proceso y sale un error de acceso invalida a memoria o algo asi.

escafandra 10-05-2008 01:14:19
Pues ese error de violación de acceso de memoria se debe a un puntero que apunta a un espacio de memoria que no pertenece a tu proceso.
Revisa tus punteros. ¿Existen todos?. ¿Alguno es nulo?.

No tiene sentido el error en Form1->RadioButton2->Checked=true; pues tanto Form1 como el hilo pertenecen a tu aplicación y por tanto es un espacio de memoria al que tienes permiso de acceso. Form1 es un puntero, como RadioButton2. Revisa con el debuguer paso a paso. ¿Que valor tienen?.

En ocasiones, fallos cometidos con puteros dan la cara mas tarde en zonas de código donde no deberían presentarse. Se debe a una corrupción de memoria.

Esa dll que usas.. ¿No estará inyectando código en otro proceso?.

En fin, el error no está donde te parece a primera vista...

Saludos.

pulpin 16-05-2008 23:47:37
Por fin una solucion parcial
 
Bueno, despues de mucho pelear encontre la solucion a mi problema y realmente es sencilla, retomando: mi problema se presentaba al inicio de la comunicacion durante 2 seg paraba mi programa por completo al llamar una funcion que en su interior contenia waitforsubject.

Realmente conocia el tiempo que se demoraba mi problema, lo que hice fue insertar un sleep antes de que se ejecutara el synchronize de mi hilo, el sleep seria controlado por una variable la cual me permitia cambiar este molesto inconveniente cuando fuese necesario.

Bueno creo que fue una solucion util, algo que conocemos pero que ami no se ubiese ocurrido en su momento.

Gracias por todo tu apoyo Escafranda. Eres (el)(la) mejor. Cuidate.:p

escafandra 19-05-2008 20:05:46
Bueno, soy el.
Saludos.


La franja horaria es GMT +2. Ahora son las 11:17:06.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi