Threads cause a crash

Hi all,
I hope someone can help me with this. I need to call the same thread multiple times, but only run one thread at a time. So what I do is create the thread which runs then drops out. Run the main loop and after some time pthread_create the same thread again. So in pseudo code

pthread
{


end thread
}


mainloop
{
create pthread

process main loop stuff

goto mainloop
}


I always presumed if I run a thread and it reaches with a pthread_exit, then the thread was destroyed? However I've found that after I've created the thread several 100 times the programme crashes? So can anyone advise how I call the same thread over and over? Thanks.

What happens when the "program crashes"? Does it print something in the console? Does it give segfault? etc.

So you are running a process, say "main", and in it you continuously create a thread, but main waits for that thread to stop, before continuing. So basically there is only one thread that has control at any one time (i.e. "main" and the child thread don't run in parallel). Is this all correct? If so, I don't see anything obviously wrong with this. However, if you are creating 100 concurrent threads, then maybe there is some threshold you are max'ing out, but this shouldn't be the case if you only execute one at a time. Alternative to "pthread_exit", try "pthread_join". I believe this blocks the caller ("main") until the given thread has finished.

If none of this helps, then post your complete code. "Complete" in a way that we can copy/paste the code into a single file, compile, run, debug, etc. If it isn't in one file, or if you can't "give away" some of the code, then minimize it as much as possible, while still reproducing the problem.

Hi thanks yes that's exactly what I'm doing. And most times I get a seg error and crash, sometimes a seg error and the software still runs but is corrupted. Sometimes a corruption but no error reported. The seg error is number 11. The corruption sort of reminds me of forgetting to free malloc'ed memory? The error always occurs after about 700 calls.

Anyway my code is simple, the thread loads some sound data onto the sound chip, however I commented this out and just use a printf statement and this still gives a seg error. Is it possible the SOUND structure is not destroyed when the thread ends, so I make 100's of SOUND *sound structures?

I call using

//Sound is a structure holding sound code
pthread_create(&sound_thread, NULL, play_sound, (void *)sound);


//thead

void *play_sound(void *ptr)
{
// tried mutex with no effect
// pthread_mutex_lock( &sound_mutex );


SOUND *sound;
sound = (SOUND *) ptr;
printf("play sound %s mutex applied\n", sound->fileame);


//took out call to sound card no effect
// snd_pcm_writei(SND_handle, sound->wavesound.sample, snd_pcm_bytes_to_frames(SND_handle,sound->wavesound.soundlength));



// pthread_mutex_unlock( &sound_mutex );

//tried to use null no effect
pthread_exit((void *) ptr);
}

Thanks

Your threads do not create any SOUND structs, they simply use the pointer passed to them each time.

I don't think the following has anything to do with your problem, but I also do not think it is necessary (correct me if I am wrong):

pthread_exit((void *) ptr);

pthread_exit(NULL);

should suffice.

Here is a chunk of code that is similar to what you're doing--and works with up to 1,000,000 threads created/destroyed (as far as I tested).

  1 # include <stdio.h>
  2 # include <stdlib.h>
  3 # include <pthread.h>
  4 
  5 // Structure passed to the threads.
  6 typedef struct {
  7   
  8   int count;
  9 
 10 } threadArg;
 11 
 12 // Thread function.
 13 void *foo(void *arg) {
 14   
 15   threadArg* argPtr = (threadArg*)arg;
 16   
 17   argPtr->count++;
 18   
 19   pthread_exit(NULL);
 20 
 21 }
 22 
 23 // Main
 24 int main (int argc, char* argv[]) {
 25   
 26   // Variable declaration.
 27   int i   = 0;
 28   int its = 0;
 29   
 30   threadArg arg;
 31   pthread_t threadObj;
 32   
 33   // Check sanity of command line arguments.
 34   if ( argc != 2 ) { 
 35     fprintf( stderr, "Proper usage: %s <iterations>\n", argv[0] );
 36     return -1;
 37   }
 38   
 39   // Grab command line argument.
 40   its = atoi(argv[1]);
 41   
 42   // Initialize count in thread structure.
 43   arg.count = 0;
 44   
 45   // Run threads.
 46   for (i=0; i<its; i++ ) {
 47     pthread_create(&threadObj, NULL, foo, (void*)&arg );
 48     pthread_join(threadObj, NULL);
 49   }
 50   
 51   // Report results.
 52   fprintf( stdout, "%d iterations were completed.\n", arg.count );
 53   
 54   return 0;
 55 
 56 }

From what you've given, I cant see anything wrong. You need to reduce your code until you feel comfortable posting it, but still reproduce the problem.

Also, please wrap your posted code with the code tags (the '#' button at the top of the message window). This will make your code much more readable.

Also, there is an upper limit on the number of threads you can have running (total, not per process). You can check this value by:

cat /proc/sys/kernel/threads-max

You can set this higher via:

echo NUM_THREADS > /proc/sys/kernel/threads-max

Where you'd replace NUM_THREADS with a new (obviously larger) value for the upper limit. I believe this would reset to the original value upon reboot. Google will tell you how to set it permanently.

Just FYI, if you'd like an example where threads are run simultaneously (likely), here one is:

  1 # include <stdio.h>
  2 # include <stdlib.h>
  3 # include <pthread.h>
  4 
  5 // Structure passed to the threads.
  6 typedef struct {
  7 
  8   int count;
  9 
 10 } threadArg;
 11 
 12 // Thread function.
 13 void *foo(void *arg) {
 14 
 15   threadArg* argPtr = (threadArg*)arg;
 16 
 17   argPtr->count++;
 18 
 19   pthread_exit(NULL);
 20 
 21 }
 22 
 23 // Main
 24 int main (int argc, char* argv[]) {
 25 
 26   // Variable declaration.
 27   int i   = 0;
 28   int its = 0;
 29 
 30   threadArg arg;
 31   pthread_t* threadObj;
 32 
 33   // Check sanity of command line arguments.
 34   if ( argc != 2 ) {
 35     fprintf( stderr, "Proper usage: %s <iterations>\n", argv[0] );
 36     return -1;
 37   }
 38 
 39   // Grab command line argument.
 40   its = atoi(argv[1]);
 41 
 42   threadObj = malloc( sizeof(threadObj) * its );
 43 
 44   // Initialize count in thread structure.
 45   arg.count = 0;
 46 
 47   // Run threads.
 48   for (i=0; i<its; i++ )
 49     pthread_create(&threadObj[i], NULL, foo, (void*)&arg );
 50 
 51   // Collect threads.
 52   for (i=0; i<its; i++)
 53     pthread_join(threadObj[i], NULL);
 54 
 55   // Report results.
 56   fprintf( stdout, "%d iterations were completed.\n", arg.count );
 57 
 58   // Clean up.
 59   free( threadObj );
 60 
 61   return 0;
 62 
 63 }

I found that I could run this with about 32k threads without hitting a segfault. Above that it would not be deterministic, until above 33k at which point it would always segfault. I have a hunch I am hitting the upper limit on my machine, but it is set to:

$ cat /proc/sys/kernel/threads-max
146432

Which means I am currently running > 100,000 threads... Seems way too high.

A quick count shows:

$ ps axm | wc -l 
546

So I have no idea why I am getting a segfault at ~32k threads. I'll let you know if I figure that out.

cat shows 2048 threads (it's an ARM board). Unfortunately using pthread_join causes problems with as it stops my main code running for a second, snd_pcm_write hangs the code for a second, that's why I have to run it through a thread.

I think I'm going to have a long think on this :s

PS sorry Xyro meant to hit quote but hit report

Originally Posted by knobby67 cat shows 2048 threads (it's an ARM board). Unfortunately using pthread_join causes problems with as it stops my main code running for a second, snd_pcm_write hangs the code for a second, that's why I have to run it through a thread. I think I'm going to have a long think on this :s PS sorry Xyro meant to hit quote but hit report

Did you try my second example with the simultaneously run threads? Test it out and see if you can find the number of simultaneous threads which gives you grief.

You absolutely must adopt a fundamentally different approach.

Since when have 2,048 individuals, all trying to do the same thing at the same time in a very confined space ("a motherboard" ...) ever succeeded at actually accomplishing anything?

Think about it: no matter how many threads you have, how many instructions can one CPU actually execute at one time? Answer (not quite correct...): one. Therefore, if you've got 2,048 threads all fighting for the CPU's attention, how much CPU-time do you think is being spent managing "all those threads," vs. actually getting any useful work done?

Consider how workflow moves through, say, a fast-food restaurant at noon. A very limited number of employees ("threads") manage a very large order-volume by efficiently managing the workflow. The number of orders in-process greatly exceeds the number of employees who are servicing them.

When you walk into the restaurant and place an order... what happens? Does someone get out a little box that says, "Instant Employee: Just Add Water!", then add water to it, then allow that newly-formed employee to fill your order, and then shoot the employee dead?

Uhh... no.

Okay, so what do the employees do when the place is really quiet? Do they shoot-to-kill everyone who isn't working?

Uhhh... no.

Design your system the way the restaurant designers did. When a new request comes in, it goes on to a queue. There is a limited (and variable) number of workers ("threads") who wake up, take the next request off the queue, carry it out, and then check the queue again. (If the queue is empty, they go to sleep.) The system will attempt to simultaneously process only as many requests as there are worker-threads, and you can control the number of threads that exist. Thread that have nothing to do are sleeping quietly.

Originally Posted by sundialsvcs Okay, so what do the employees do when the place is really quiet? Do they shoot-to-kill everyone who isn't working? Uhhh... no.

As someone who works in an arguably high-class dining facility in Yosemite, let me tell you that "no" does not always tell the full story here.

Originally Posted by sundialsvcs You absolutely must adopt a fundamentally different approach. Since when have 2,048 individuals, all trying to do the same thing at the same time in a very confined space ("a motherboard" ...) ever succeeded at actually accomplishing anything?

But if you check out my posts I'm not running that number of threads. I'm only running I one, then destroying it.

And then there's the fact that multicore CPUs can handle multithreaded apps much better.