• "Heinz-Peter Nüttgens" <heinmueck58 gmx.de> Jun 18 2004
• Arjan Knepper <arjan ask.me> Jun 23 2004
• "Heinz-Peter Nüttgens" <heinmueck58 gmx.de> Jun 23 2004
• Arjan Knepper <arjan ask.me> Jun 23 2004

Hello,

once again I post a question to that topic, which makes me get grey hair.

In my application I start a thread to handle commands for a hardware. This
thread is controlled by the main thread by Events whether it should do
something or not. When I advise the command-thread to do something and wait
for its completion, this takes min. 16ms (Windows XP, P4 2.4GHz, 512MB-RAM).
Measuring the time of the command thread, it takes less than 1ms.

Therefore I suppose, there is an overhead during Taskswitching which lasts
for at least 16ms. What I want is to minimize this time, because I want to
increase the command rate. When initiating and executing the commands in one
thread, the execution speed is very good and it's no problem to go below 1ms
per command. But I can't go that way, because under normal circumstances
when the application is running on recent, quite fast, computers, there is a
kind of multithreading in the windows message system, which cause the
initiation of command while other commands are executed. Therefore I chose
mutlithreading as a solution.

Perhaps somebody can help

Greetings

Heinz-Peter

Do you also have this "delay" using other compilers? iaw is it OS 
related or is it compiler related?

You are aware of the possibility to give an certain thread a higher 
priority?

Also what do you mean with:
 when the application is running on recent, quite fast, computers, there is a
 kind of multithreading in the windows message system, which cause the




 initiation of command while other commands are executed.




Arjan

Thanks Arjan,

I don't have a comparison to other compilers, but I think it is caused
by the OS. It isn't the thread itself, which takes that time. The time ist
spent during
a "WaitForMultipleObjects" call in the first thread which waits for an event
which is set and reset
in the second thread. Measuring the time of the two threads shows that
thread 2 takes less than 1ms
over all. The first thread, waiting for the second to set the event takes
min. 16ms for this.
My explanation is that something in the OS takes such a long time. Maybe
taskswitching itself takes that time
or recognizing the event state may last.

Sure I tried to vary the thread priority, without any significant result,
because the time which is spent by the thread
isn't that long. But I can't find a way to get a quicker reaction to the
threads status change.

First of all I started the second thread and waited for it to finish. With
the same result I thought the creation
and handling of teh new thread would take so long. Therefore I changed to a
free running thread control by events.

Greetings

Heinz-Peter


"Arjan Knepper" <arjan ask.me> schrieb im Newsbeitrag
news:cbbab7$23h4$1 digitaldaemon.com...
 Do you also have this "delay" using other compilers? iaw is it OS
 related or is it compiler related?

 You are aware of the possibility to give an certain thread a higher
 priority?

 Also what do you mean with:
 when the application is running on recent, quite fast, computers, there






 kind of multithreading in the windows message system, which cause the




 initiation of command while other commands are executed.




 Arjan

Heinz-Peter Nüttgens wrote:
 Thanks Arjan,
 
 I don't have a comparison to other compilers, but I think it is caused
 by the OS. It isn't the thread itself, which takes that time. The time ist
 spent during
 a "WaitForMultipleObjects" call in the first thread which waits for an event
 which is set and reset
 in the second thread. Measuring the time of the two threads shows that
 thread 2 takes less than 1ms
 over all. The first thread, waiting for the second to set the event takes
 min. 16ms for this.


When you make only the first 'waiting' thread a higher priority, does 
the 'delay' decrease? Or does it make no difference at all?

 My explanation is that something in the OS takes such a long time. Maybe
 taskswitching itself takes that time
 or recognizing the event state may last.


I don;t know how expensive taskswitching is or how long it will take for 
a 'wait' api call to recognize the event-state chnage. Have you tried 
other sync object like Crical Sections? I have no idea whether or not it 
will improve performce.

 Sure I tried to vary the thread priority, without any significant result,
 because the time which is spent by the thread
 isn't that long. But I can't find a way to get a quicker reaction to the
 threads status change.
 
 First of all I started the second thread and waited for it to finish. With
 the same result I thought the creation
 and handling of teh new thread would take so long. Therefore I changed to a
 free running thread control by events.


So you're saying the creation and deletion of the thead object is as 
fast as two free free running threads using events?

Arjan