Shutdown of Threads

[cecil_rabmere]

I have a thread which will be created x amount of times depending on what the user inputs via standard in. They are all going to read from a file, what's the best way to signal them all to shutdown? I tried using a boolean value within the while( 1 ) loop, with no luck. Thanks!

[matsp]

What is the actual reason that they should shut down?

--
Mats

[C_ntua]

What library are you using for the threads?
A simple way is

while (...) {
if (!run)
   _endthread(); //or sth similar depending on the library. Maybe even return might work

Now, you could use signals. Like with pthreads use the pthread_kill(...) function. But that is more complicated.

Post your thread function code if you want. A code like you said:

while (run) {
...
}

with run a global variable should work also, dunno why it doesn't work for you

[cecil_rabmere]

My main()'s job is to read from a file and innitiate a bunch of threads. Those threads than use the take() method to get a single line from a file. Eventually my main() is done processing file than triggers the boolean value quit to be true. The thread's should all shut down then...Also, I have no idea if i'm using strtok_r() right, I tried a few different ways. Thanks, feel free to ask any questions about the code.

void *thread( void *dummy )
{

  // the consumer thread's local histogram array
  ulong hist[ HISTOGRAM_SIZE ];

  char *saveptr;  // for strtok_r (not sure how to use properly)
  char *token;    //words in a line
  char *item;

  int length;

  int i=0;

  // initialize the array to all zeroes
  for(i = 0; i < HISTOGRAM_SIZE; i++)
      hist[i] = 0;

  // take and process items till shutdown
  item = take(); //get a line from a file
  while( 1 && !quit )//check it's not time to quit
  {
	while( (token = strtok_r( item, DELIMS, &saveptr )) != NULL  ) //get all the tokens in the line
	{
	   //token = strtok_r( item, DELIMS, &saveptr );
	   item = saveptr;

	   printf( "%s", token );

	   length = strlen( token );   //length of the word
	   if( length < 10 )
	   		hist[ length - 1 ] += 1;  //category 1 to 9
	   else
	   		hist[ HISTOGRAM_SIZE - 1 ] += 1; //category 10+
	}

    item = take(); //get next item
  }// while

  //Use mutex to lock, were adding a local array's values to a global array's values
  pthread_mutex_lock( &histogram_lock ); 

  //cycle local array totals adding to global
  //array totals
  for( i=0; i < HISTOGRAM_SIZE; i++ )
      histogram[ i ] += hist[ i ];

  pthread_mutex_unlock( &histogram_lock ); //unlock

  pthread_exit(NULL);

} // end consumer_thread

[matsp]

You may need to declare quit as volatile to make sure that the compiler re-reads it, and doesn't store the original value in a register.

--
Mats

[Codeplug]

volatile has no use in pthread programming (or multi-threading in general - as I like to argue).

Under Posix, any shared access to memory, like 'quit', must be properly synchronized.

Why not just have take() return NULL when it's time to exit.

>> printf...
You should synchronize access to 'stdout' to prevent "mangling" of strings.

gg

[mynickmynick]

what kind of problems you encounter with that design ? not all threads exit?

quit should be protected via mutex_lock unlock
but as you only test it as equal or different by zero this might give no rush condition

might be as it is not volatile the compiler does not force an update of the value??
might be some of the operation inside the loop hang cause there is not anymore anything to do (another thread has rushed and finished things to do)??

try with a sem_getvalue(Quit_semaphore..

[cecil_rabmere]

Ya not all threads exit. I was thinking about pumping a "QUIT" string into the mix so that when take() is issued eventually the thread will recieve a QUIT string and I'll test for that. But I'm assuming i'll have to do that for each thread, so pump a "QUIT" variable in for each thread that exists via my main() method after it's done reading the file. Does that sound like a good idea?

Does the strtok_r() usage look correct? I've never used it and i'm not 100% sure about it...

[mynickmynick]

Ya not all threads exit. I was thinking about pumping a "QUIT" string into the mix so that when take() is issued eventually the thread will recieve a QUIT string and I'll test for that. But I'm assuming i'll have to do that for each thread, so pump a "QUIT" variable in for each thread that exists via my main() method after it's done reading the file. Does that sound like a good idea?

probably take hangs cause another thread has finished everything has to be done while main did not update quit yet

[C_ntua]

Well, can't say what is wrong. Post all the code, do see what happens with the variable quit.
Though, do this basic debugging first:
1) See if the threads exit from the while loop by puting a printf after the while.
2) See how many threads exit by putting a printf at the end

this will help you see what exactly goes on...

[mynickmynick]

try this

 
  while( 1 && !quit )//check it's not time to quit
  {

	while( (token = strtok_r( item, DELIMS, &saveptr )) != NULL  ) //get all the tokens in the line
	{
	   //token = strtok_r( item, DELIMS, &saveptr );
	   item = saveptr;

	   printf( "%s", token );

	   length = strlen( token );   //length of the word
	   if( length < 10 )
	   		hist[ length - 1 ] += 1;  //category 1 to 9
	   else
	   		hist[ HISTOGRAM_SIZE - 1 ] += 1; //category 10+
	}
**  lock mutex for items

    item = take(); //get next item

*** if nothing left to do : quit++; //so quit is updated by any thread (not only by main)
*** unlock mutex for items

  }// while

Please try this . I am interested

[cecil_rabmere]

Mutex already exists within the take() function, as well as condition variables. It works in conjunction with append() much like a producer consumer problem. If you like, I can post all the code, it's a couple hundred lines though.

[Codeplug]

Unsynchronized access to memory results in undefined behavior - as is the case when reading 'quite' in the while condition - why try to debug it?

>> Please try this
Still undefined, so shouldn't be interesting - except to show take() may be deadlocking threads due to asynchronous access

>> Does the strtok_r() usage look correct?
No.
http://www.opengroup.org/onlinepubs/...ns/strtok.html
After the first call, the first parameter should be NULL.

>> It's a couple hundred lines though
Your threads may be stuck within take().

gg

[mynickmynick]

Mutex already exists within the take() function, as well as condition variables. It works in conjunction with append() much like a producer consumer problem. If you like, I can post all the code, it's a couple hundred lines though.

no I have not much time

BUT : do you update quit++ inside take() if no work is left? I think that might be the problem

[mynickmynick]

Unsynchronized access to memory results in undefined behavior - as is the case when reading 'quite' in the while condition - why try to debug it?

Ok I agree but in this case what is likely to happen?
if quit is only tested as !quit
or updated via quit++
what undefined behaviour might happen?

might be in that loop quit is not updated cause the compiler does not know quit is a shared variable so does not read in memory at each iteration?