Board index » cppbuilder » Re: how to keep a thread alive without a CPU-hogging infinite loop

2005-09-01 05:14:52 AM
cppbuilder52
"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
where the component is. They need to use Synchronize to get anything to the
main thread. Even if there were some way to make a component in one thread
use an event handler in another thread, how would that other thread (my main
application thread in this case) then know which thread to send the command
back to? The event handler's parameters don't include an indication of
which thread initiated the event.
Then even dealing with commands that do start from the main thread, if it
simply called a member function of the thread to insert a command object
into the queue, how would that member function run? The thread is blocked
until it sees the object in the queue, so how can it be functioning to place
it's own wakeup call there?
 

In article <4314d475$ XXXX@XXXXX.COM >, XXXX@XXXXX.COM
says...
while (WaitingForResults){
Application->ProcessMessages();
SleepEx(1,true);
}
With SleepEx the thread goes to sleep for 1 ms and releases control to
other processes.
OR
you can send thread messages with
PostThreadMessage(m_WriteThread->ThreadID,myDOTHREAD_CLOSE,0,0);
and use the following code in the treads execute:
while((!Terminated)&&(l_boolEndThisThread==false))
{
if(PeekMessage(&msg,0,0,0,PM_REMOVE))
{ if(msg.hwnd != NULL)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}else
{
switch(msg.message){
case myDOTHREAD_CLOSE:
l_boolEndThisThread = true;
break;
// case :
// and so on
};//end of switch(msg.message)
}
}
SleepEx(1,true);
}
Hope this wil do better
 

"LesleyAnne" < XXXX@XXXXX.COM >writes:
which must run in the main thread. Maybe I missed that you were using
some other type of event handler.
If you are somehow processing "events" in your worker thread already,
then you don't need a blocking message queue, since that's used for
communication between threads.
you know which thread you're talking to based on which message queue
you're using.
More typically, though, the main thread would tell the other threads
what to do, not the other way around (because the main thread isn't
waiting on a condition variable... it's processing the main
application event loop.)
distorting reality. A thread isn't a class. It is a lightweight
process running in the same address of your application, with its own
stack frame and instruction pointer. A "thread object" is an attempt
to make an object LOOK like a thread, but really it simply is a normal
object that happens to also spawn a thread that runs a function that
is in that class. But OTHER threads can call member functions on this
thread-object, since it still is, afterall, just an object.
signals the condition variable that the other thread is blocked upon.
That wakes up the sleeping thread, who then checks that the queue is
not empty (which it isn't), and so it breaks out of its wait-loop, and
dequeues the command and processes it. Once it is finished processing
that command, it calls pop() on the queue again, which blocks until
another message is available.
--
Chris (TeamB);
 

{smallsort}

Hans Zandbergen < XXXX@XXXXX.COM >writes:
sleep into the equation may solve or reduce the CPU problem, but it
introduces some pretty significant delays (in computer terms) between
when something needs to be handled and when it actually gets handled.
--
Chris (TeamB);
 

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
thread until either an event occurs on a component in this thread or the
main thread calls one of this thread's functions.
The setup is one main thread that spawns multiple child threads (multiple
instances of the same TThread descendant class). Each child thread creates
its own TClientSocket to communicate with a remote machine. It should close
the connection and terminate either when the communication is finished or
when the main thread tells it to.
It sounds like I have a choice between:
(1) Make the TClientSocket a blocking socket, which allows the socket
connection to function but nothing else, so the main thread cannot
communicate with the child thread.
(2) Add in a blocking message queue, which would allow the main thread to
talk to the child thread, but sounds like it would block the ClientSocket,
which won't work.
or (3) don't use blocking in the child thread at all, which will allow both
the TClientSocket to work and also allow the parent thread to communicate
with it, but with no blocking it will take up 100% of available CPU time
just by continually checking the "while (WaitingForResults)" or "while
(!Terminated)" condition.
I've tried options (1) and (3), both of which work, but both of which have
drawbacks.
[Actually, option (1) has an additional drawback in that it's specific to a
TClientSocket only. I'd prefer a solution that would work more generically
on any non-visual component(s), but I don't know how to say "block until an
event occurs".]
 

"Hans Zandbergen" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
There is one problem that I can't tell quite what some of the functions are
doing because my Builder6 help files don't contain any mention of
PostThreadMessage or PeekMessage, and there's only indirect references to
TranslateMessage and DispatchMessage in a couple of example pages, but no
explanation of them. Can anyone recommend a reference to how these (or
other) message functions work?
Ideally, I'd like a blocking version of PeekMessage, so that that SleepEx at
the end wouldn't be necessary. (At least it sure seems as though "wait
until there's a message to be processed, then process it" would be a
standard enough pattern for such a function to exist.)
 

"LesleyAnne" < XXXX@XXXXX.COM >writes:
adds problems that I am not familiar with.
ACE has a "reactor" framework, which can basically implement exactly
what you want. Each thread could run its own reactor loop, which
basically waits until "somthing happens", with that something being
either I/O (in this case, socket activity), or an asychronous
notification, which would be an alternate way of "poking" the reactor
to wake up and invoke its notification.
On another question, why do you need threads to handle your network
connections in the first place? Why not just handle all the sockets
in the main thread?
--
Chris (TeamB);
 

"LesleyAnne" < XXXX@XXXXX.COM >wrote in message
while (WaitingForResults)
{
Sleep( 1000 );
}
HTH
Jonathan
 

LesleyAnne wrote:
I don't know about VCL's TThread and TClientSocket, but with the
plain C versions, non-blocking communications use events which you can
wait on. You can also create your own events that the main thread can
signal to wake up the thread. The thread then waits for the
communications events as well as the main event. It processes
whichever event woke it up.
 

"LesleyAnne" < XXXX@XXXXX.COM >wrote in message
found it in some help files left over from Builder5. It looks like this
should work, and I can replace the SleepEx at the end of that while loop
with a WaitMessage() at the beginning to avoid the sleep delay.
Either that or I may use the WaitForMultipleObjects() suggested in another
post. I'll try each and see which works best.