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
is a
> >> 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