Thread problem...

[Moonlit]

Hi,

On most OS'es you would (should) wait for an event to happen. If you just
increase a variable the system is spending all its time doing that. You
might want to use 'poll' or 'select' to wait until someone inputs something
or in a polling application use sleep().

Regards, Ron AF Greve.

 

[Maximus]

Hi,
I'm trying to create a thread (never did before) to constantly look at a
combo box value but my thread take 100% of the processor, a thing I don't
want to. First is it normal and second if first is no what's my error in my
codes:

int test = 0;
{....}
HANDLE thread = createTriggerThread((void*)HWnd);
if(NULL!=thread)
SetThreadPriority (thread, THREAD_PRIORITY_NORMAL);
{....}

HANDLE createTriggerThread(void*pThis)
{
return ::CreateThread(NULL,0,(unsigned long (__stdcall*)
(void*))TriggerThread,(void *)pThis,0,NULL);
}
void TriggerThread(void*pThis)
{
do
{
test++;
} while(1);
}

What am I doing wrong????

Thanks,
Max.

 

[Phlip]

I'm trying to create a thread (never did before) to constantly look at a
combo box value but my thread take 100% of the processor, a thing I don't
want to. First is it normal and second if first is no what's my error in my
codes:

Firstly, you have a busy loop: while(1). That's what trashes your CPU - it
spends all its time servicing your thread, unaware it's not doing anything.

Secondly, if you absolutely must thread, use _beginthread(), not
CreateThread(). The former initializes the thread's C runtime library
features.

Thirdly, our industry horribly over-uses threads. Your documentation will
not tell you this, but the only reason to ever use them are certain hardware
and device driver shenanigans.

Fourth, the point of GUI programming is to write "event driven" code. When
that combo box changes it is already sending your window several messages
describing exactly how it change. If your code simply declared handlers for
these notifications (search for WM_NOTIFY to learn how), then you could
write a small function that only does exactly want you need with the event.
Using events to drive programs tends to force your code to use a complete
object model to store all its facts, and this technique makes threads very
unlikely.

Fifth, all this is off-topic here. Other newsgroups are better qualified to
help with platform-specific code. We try to only discuss platform-neutral
topics. (But those newsgroups might not advise against threads!)

 

[EventHelix.com]

Using a thread for monitoring a combo-box is an overkill.

If you are programming in Windows, you can just override an
event for the combo box.

Sandeep

 

[Stewart Gordon]

While it was 29/11/03 1:09 pm throughout the UK, Phlip sprinkled little
black dots on a white screen, and they fell thus:

Thirdly, our industry horribly over-uses threads. Your documentation will
not tell you this, but the only reason to ever use them are certain hardware
and device driver shenanigans.

<snip>

So, what would you use instead to carry out calculations without
blocking user input e.g. to interrupt the calculation?

Stewart.

 

[Phlip]

Stewart Gordon stands accused of writing:

While it was 29/11/03 1:09 pm throughout the UK, Phlip sprinkled little
black dots on a white screen, and they fell thus:

<snip>

So, what would you use instead to carry out calculations without
blocking user input e.g. to interrupt the calculation?

I personally believe there is no possible algorithm that would not
benefit from expression as an object model with discrete events to
change it towards its solution, but the science isn't advanced enough
yet to refute or support me.

In practical programming terms, if you are driving with one hand and
eating a sandwich with the other, use threads.

But the documentation for threads typically provides very poor role
models. It might show examples of waiting at two COM ports at the same
time. While this assists those who already think they need threads, it
might disadvantage programmers who need to wait at two COM ports at
the same time and think the example code shows the "standard" way to
do it. All multitasking OSs support a 'select' or Multiplex system to
await any set of multiple events at the same time. Using them will
force your code that responds to those ports to show a better design.

I know a programmer who heard of threads before they heard of the
Win32 message architecture's notification system. That is pleasantly
synchronous and robust.