This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
#include <stdio.h> #include <pthread.h> #include <sys/syscall.h> #define gettid() syscall(__NR_gettid) #define NUMBER_OF_THREADS 70 int my_test_func(unsigned int num) { unsigned int i=0; unsigned int total=0; for(i=0; i<num; i++) total += i; return total; } void * thread(void * arg) { while(1) { printf("I am pthread %d.\n", gettid()); if( (unsigned int)arg == NUMBER_OF_THREADS ) { my_test_func(100); sleep(5); } else { sleep((unsigned int)arg * 30); } } } int main(void) { pthread_t id; int i,ret; for( i=1; i<=NUMBER_OF_THREADS; i++) { ret=pthread_create(&id,NULL,(void *)thread,(void*)(i)); if(ret!=0){ printf ("Create pthread error!\n"); return -1; } } printf("This is the main process %d.\n", gettid()); pthread_join(id,NULL); return (0); }
#include <stdio.h>
#include <pthread.h>
#include <sys/syscall.h>
#define gettid() syscall(__NR_gettid)
#define NUMBER_OF_THREADS 70
int my_test_func(unsigned int num)
{
unsigned int i=0;
unsigned int total=0;
for(i=0; i<num; i++)
total += i;
return total;
}
void * thread(void * arg)
{
while(1)
{
printf("I am pthread %d.\n", gettid());
if( (unsigned int)arg == NUMBER_OF_THREADS )
{
my_test_func(100);
sleep(5);
}
else
{
sleep((unsigned int)arg * 30);
}
}
}
int main(void)
{
pthread_t id;
int i,ret;
for( i=1; i<=NUMBER_OF_THREADS; i++)
{
ret=pthread_create(&id,NULL,(void *)thread,(void*)(i));
if(ret!=0){
printf ("Create pthread error!\n");
return -1;
}
}
printf("This is the main process %d.\n", gettid());
pthread_join(id,NULL);
return (0);
}
Hi,
I have tested and ran several Linux multi-threaded applications in the past without problems or special configurations, but they usually had a much smaller number of threads when compared to yours - that could quickly overload the GDB debugger.
Also, certain releases of GDB had trouble when debugging multi-threaded applications, but I recall they were part of older versions of the GNU toolchain.
That said, the component used to debug GDB applications is completely open source and therefore we can't control its features, functionality or performance. In this case I strongly suggest to take a look at the telated threads below:
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/138629/561527.aspx
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/123247.aspx
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/146092.aspx
Hope this helps,
Rafael
Hi Rafael:
Thanks for your reply and suggestion. I understand there is not problem when the multi-threaded application only have several threads. If I reduce the threads number less than 5, although we can notice the state change of resuming then suspending all threads during each single step, overall, the performance is at a acceptable level.
I tested it is no problem if I run gdb from command line to perform the same debugging operations, so I suspect the overhead is introduced by GUI. also I tested on Eclipse-CDT, I can observe the same problem if the process has large number of threads.