time consumption by creating/destroying threads

[Omega]

Hi,

I'm a student working on a report about a piece of software (C++, linux) that I've written. The major tasks that this software executes are:
>create a string based on called function (just a couple of integers converted to 'chars')
>open a thread (using pthread_create)
- main thread: start (deadlock) timer
- new thread: execute client functions for (wireless) communication (send string to server)
>main thread checks for answer every 1 ms (if timer reaches certain limit -> cancel thread to avoid deadlock)
>return answer

I've tested the performance of this software and it appears that the communication part (everything that happens inside the new thread) took about half the time (10 ms). This means that the other half is consumed by other functions. I think that is quite a lot (the software runs on a 200 MHz ARM9 processor).
Can I conclude that this is a result of the thread that I create every time before communication? Or doesn't that take that much time? Would it be faster to create the thread only 1 time and use an infinite loop inside that polls a variable in order to know when it should execute communication routines?

Unfortunately I don't have the time to do some tests with modified software, so hopefully someone can tell me what the bottleneck is in above mentioned software (just for recommendations in the report).

Thanks in advance!

[Arulmurugan]

Hi,

I'm a student working on a report about a piece of software (C++, linux) that I've written. The major tasks that this software executes are:
>create a string based on called function (just a couple of integers converted to 'chars')
>open a thread (using pthread_create)
- main thread: start (deadlock) timer
- new thread: execute client functions for (wireless) communication (send string to server)
>main thread checks for answer every 1 ms (if timer reaches certain limit -> cancel thread to avoid deadlock)
>return answer

I've tested the performance of this software and it appears that the communication part (everything that happens inside the new thread) took about half the time (10 ms). This means that the other half is consumed by other functions. I think that is quite a lot (the software runs on a 200 MHz ARM9 processor).
Can I conclude that this is a result of the thread that I create every time before communication? Or doesn't that take that much time? Would it be faster to create the thread only 1 time and use an infinite loop inside that polls a variable in order to know when it should execute communication routines?

Unfortunately I don't have the time to do some tests with modified software, so hopefully someone can tell me what the bottleneck is in above mentioned software (just for recommendations in the report).

Thanks in advance!

Normally thread creation never takes too much time, and there is no way to create thread very faster/slower.

May be you could create a thread at the starting then you can make use the same thread, here also polling is not a better idea.Use mutex and conditional veriables.

regards,
Arul

[weaknessforcats]

You are aware, I hope, that each time the OS swtiches between your threads it has to do a context switch ??.

That is, any multi-threaded program is goind to run slower than than a single-threaded program because of these context switches. The only advatage to multi-threading is to conceal a time comsuming opreration.

That doesn't appear to be the case here. Have you considered running this as a single threaded program??

[Arulmurugan]

You are aware, I hope, that each time the OS swtiches between your threads it has to do a context switch ??.

That is, any multi-threaded program is goind to run slower than than a single-threaded program because of these context switches. The only advatage to multi-threading is to conceal a time comsuming opreration.

That doesn't appear to be the case here. Have you considered running this as a single threaded program??

Hi,
Really thread context switching isl not OS procecss/kernelthread context switching. when you compare process context switch with thread context, thread switching very very less.

Multithreaded application more interactive in uniprocessor system, and it more powerful in SMP env.

So i don't think for this original problem the thread context switching does matter.

Regards,
Arul

[weaknessforcats]

Still, your primary thread has to be stiored away, registers unloaded, the working thread loaded, registers restored - AND these are the same registers used by the kernel.

Maybe with muliple core you save but not on a single processor machine.

The kernel swtich you are taling about is that done by the scheduler as it changes the active process. However, this is usually done by a remap of the page table so no actual data has to move. No so with a context switch within a process.

In any case, a multithreaded program will run slower than a single threaded one on a single code machine. Has to. The context switches, however small, are atill larger than no context switches at all.