waiting for another thread without blocking resources...

Lars Uffmann schrieb:

In an event routine, I want to end a certain thread. I am setting a flag
that is checked by the thread and causes it to end, when it is set. Then
the thread sets a "response" flag, just before exiting. In the event
routine, I would like to wait for that response flag, because at that
point, I can be sure that the old thread (even if it still is alive
between setting the response flag and exiting) will no longer interfere
with a subsequent call.

However, a

while (!responseflag);

heavily blocks system resources and apparently also the read call blocks
the writing of the responseflag - I get caught in an endless loop there.

If you want to wait in a thread, you should not use a loop, but simply
wait. There might be some functions like WaitForSomeCondition() in your
threading library, and you should ask this question in a newsgroup about
your platform or threading library.

--
Thomas
http://www.netmeister.org/news/learn2quote.html
"Some folks are wise, and some otherwise."

On Feb 14, 10:59*am, Lars Uffmann <a...@nurfuerspam.dewrote:

while (!responseflag);

heavily blocks system resources and ...

It can improve you situation a little bit, if you release the
processor while waiting, e.g.:

while (!responseflag) sched_yield();

Of course, the actual instruction for yielding depends on what library
you are using.

However, you might consider using a semaphore for event signaling.

Best Regards,
Szabolcs

Thomas J. Gritzan wrote:

If you want to wait in a thread, you should not use a loop, but simply
wait. There might be some functions like WaitForSomeCondition() in your
threading library, and you should ask this question in a newsgroup about
your platform or threading library.

boost only has a mailing list :/
And the thing is, actually my event procedure is not a thread. I was
hoping there was some way to have a button that starts and ends a thread:

First Click:
-set keepalive flag, start thread, thread set's a "i'm running" flag,
then checks keepalive flag every cycle

Second Click:
-unset keepalive flag, wait for "i'm running" flag to be un-set,
thread ends upon next check, unsets "i'm running"

For that I only have 1 thread, and the event procedure cannot be a
thread, nor should it be. There's got to be some c++ sleep function that
gives the thread some time to terminate, without blocking resources...

Or isn't there?

*confused*

Lars

Hi Yannick,

Thank you very much for your extensive reply - that seems to be shedding
some light on threading for me, but since I'll need some time to do what
you suggested, I wanted to post a quick reply first :)

Best Regards,

Lars

Cholo Lennon wrote:

PS: Could you provide some code to check the library use?

boost::thread *THREAD_FileReceiver; // global variable
int GLB_listen = 0; // global
int GLB_listening = 0; // global

// event handler function
void OnToggleListen()
{
if (!GLB_listen) {
if (GLB_listening) {
cout << "error: still ending thread" << endl;
return;
}
GLB_listen = 1; // set keepalive flag for thread
cout << "starting thread" << endl;

// this function is the threads main loop, receiving UDP packets
THREAD_FileReceiver = new boost::thread(&listenForUDPFiles);

// wait for thread to set GLB_Listening := 1 - how??

// the following is the cmd button to toggle thread status
mainWindow->cmdToggleListen->SetLabel ("Stop Listening");
}
else {
if (!GLB_listening) {
cout << "error: still starting thread" << endl;
return;
}
GLB_listen = 0; // unset keepalive flag for thread

// send a UDP packet to get thread out of listening mode
sendEndOfStream();

cout << "waiting for thread to end" << endl;
THREAD_FileReceiver->join();
cout << "thread finished, GLB_listening = " << GLB_listening << endl;
delete THREAD_FileReceiver;
THREAD_FileReceiver = 0;

// the following is the cmd button to toggle thread status
mainWindow->cmdToggleListen->SetLabel ("Start Listening");
}
}

---
this code just crashes after the join() call while without it, the code
would exit normally. However, then I have a possible race condition when
re-activating the thread. Are you able to make anything from that?

Thanks,

Lars

On Feb 15, 10:58 am, Lars Uffmann <a...@nurfuerspam.dewrote:

Cholo Lennon wrote:

PS: Could you provide some code to check the library use?

boost::thread *THREAD_FileReceiver; // global variable
int GLB_listen = 0; // global
int GLB_listening = 0; // global

// event handler function
void OnToggleListen()
{
if (!GLB_listen) {
if (GLB_listening) {
cout << "error: still ending thread" << endl;
return;
}
GLB_listen = 1; // set keepalive flag for thread
cout << "starting thread" << endl;

// this function is the threads main loop, receiving UDP packets
THREAD_FileReceiver = new boost::thread(&listenForUDPFiles);

// wait for thread to set GLB_Listening := 1 - how??

// the following is the cmd button to toggle thread status
mainWindow->cmdToggleListen->SetLabel ("Stop Listening");
}
else {
if (!GLB_listening) {
cout << "error: still starting thread" << endl;
return;
}
GLB_listen = 0; // unset keepalive flag for thread

// send a UDP packet to get thread out of listening mode
sendEndOfStream();

cout << "waiting for thread to end" << endl;
THREAD_FileReceiver->join();
cout << "thread finished, GLB_listening = " << GLB_listening << endl;
delete THREAD_FileReceiver;
THREAD_FileReceiver = 0;

// the following is the cmd button to toggle thread status
mainWindow->cmdToggleListen->SetLabel ("Start Listening");
}

}

---
this code just crashes after the join() call while without it, the code
would exit normally. However, then I have a possible race condition when
re-activating the thread. Are you able to make anything from that?

Yes, it's possible that you have a race condition. Try locking the
section. Global variables aren't good, but using the same scheme:

....
boost::mutex GLB_mutex;

void OnToggleListen()
{
boost::scoped_lock(GLB_mutex);

// your code ...
}

Also, try locking global variable access in your thread function.

void listenForUDPFiles()
{
...

// Access shared flags (GLB_listen, GLB_listening)
{
boost::scoped_lock sl(GLB_mutex);

// update flags here
}
...
}

TODO: 1st Check if the solution work. 2nd Remove global variables and
optimize locking.
Regards

--
Cholo Lennon
Bs.As.
ARG