linux multithreaded programming

gargoyle

A procedure
pthread_t thread [5];
pthread_mutex_t mut;
pthreat_cond_t cond
.
void Creat_Thread (char * p)
{
 pthread_create (&thread [n], NULL, thread1, (void *) p);
}

void * thread1 (void * p)
{
  .....
  while (1)
{
pthread_mutex_lock (&mut);
pthread_cond_wait (&cond,&mut);
.......... processing function 1;
Processing function 2;
Processing function 3;
Processing function 4;
pthread_mutex_unlock (&mut);
}
pthread_exit (NULL);
}
.
.
int main ()
{
  Initialize mutex and condition variables;
. . . .
 for (i = 0; i <5; i ++)
     Creat_Thread (p [i]);
do
{
  pthread_cancel (thread [4]);
  pthread_cond_signal (&cond); // Send a signal
 } while (1);
 thread_wait ();
 return 0;
}
The program compiles. Now the problem is that when the multi-threaded program is running, when the thread is created (that is, when the for loop creates the thread), it runs correctly (all processing functions run correctly), but then it runs using the mutex and condition variables. When all threads run to processing function 3, processing function 4 is not running; I don't know what the reason is;

zjwzjw

Look at the logical process of the program...

orangedj

void Creat_Thread (char* p)
{
pthread_create(&thread[n], NULL, thread1, (void *)p);
}

Where did n come from? Is there a missing parameter?

gargoyle

The program logic is executed sequentially,
Is Creat_Thread(char* p, int n)

orangedj

Print more information

281167814

Which thread sends pthread_cond_signal?

281167814

When pthread[4] is canceled, the thread may not release the mutex,
Because pthread_cond_signal is a cancel point, the thread may end here

281167814

In addition, before calling pthread_cond_signal, you must add a mutex, otherwise,
It may be because pthread_cond_wait loses protection when comparing test conditions with memory
And the order is chaotic
After calling pthread_cond_signal, unlock