关于多线程中运用pthread_cond_wait的问题

cquptcqupt2

在主线程中开了两个线程thread1和thread2，目的是thread1执行一次就通知thread2执行一次。

其中thread1中,用signal(SIGALRM,encode)和setitimer做为定时触发器,定时执行encode()函数,在encode函数中有pthread_cond_broadcast函数来触发thread2函数的执行。

    问题:当定时器为66ms一个周期的话,计算执行300次所需要的时间拿，手表加打印输出为20s，说明正常。当定时器为40ms一个周期,执行500次，理论上执行这500次应该是20s，但确花了43秒,多次测试都差不多这个数。
不知道问题会出在哪里，会不会thread1线程或者thread2线程多霸占了一些时间。


大概代码:
thread1中的encode,此函数每隔一定周期被执行一次
     pthread_mutex_lock(&mutex_encode_record)
             逻辑变量1    = 1；
             逻辑变量2    = 0；
                  业务函数（）；
         逻辑变量1    = 0；
         逻辑变量2    = 1；           
   pthread_mutex_unlock(&mutex_encode_record);
    pthread_cond_signal(&cond_enc_end);
   
在thread2中
     while(1)
       {
                    while(逻辑变量2 ==0 || 逻辑变量1 == 1)
                                pthread_cond_wait(&cond_enc_end,&mutex_encode_record);

                 业务函数();//此业务函数就是写文件,很小数据,时间忽略不计
                逻辑变量1  == 1;
                  pthread_mutex_unlock(&mutex_encode_record);


     }

cquptcqupt2

刚才把可能会影响的条件都组合测试了一下,开始的时候组合反正都不对，最后还原成原始后居然时间没问题了。
奇怪。

lgfang

先说两句题外的：
我觉得没有目的的乱试是没有意义的，没有思路前先别动代码，仔细琢磨（或问人）。有句话说的好：don't just do something.

thread1中的encode,此函数每隔一定周期被执行一次
     pthread_mutex_lock(&mutex_encode_record)
             逻辑变量1    = 1；
             逻辑变量2    = 0；
                  业务函数（）；
         逻辑变量1    = 0；
         逻辑变量2    = 1；           
   pthread_mutex_unlock(&mutex_encode_record);
    pthread_cond_signal(&cond_enc_end);

最后两行是不是应该换个位置？
还有，消费者一开始的时候是不是应该先锁住mutex？

建议看看unix network programming volumn 2: IPC

cquptcqupt2

问题大概解决,有待进一步确认。
上面代码没错,
在encode()函数中里面又调用了另一函数getdata(void* yuvdata)
其中 YUVdata定义
typedef YUVdata{
    unsigned char* data[3];//
}YUVdata;

我已开始是在encode中在调用getdata时候,将参数类型YUVdata转换成void类型,然后在getdata函数
中将void类型转换成YUVdata类型再处理.这样就会出现顶楼的问题。

现在将getdata(void* yuvdata)改成getdata(YUVdata* yuvdata)暂时没事.

ps:楼上大哥说的对在消费者那边忘记写上lock了,代码中有的

[ 本帖最后由 cquptcqupt2 于 2007-4-27 14:18 编辑 ]

lgfang

现在将getdata(void* yuvdata)改成getdata(YUVdata* yuvdata)暂时没事

应该和这个无关吧。 刚才查了查 UNP v.2，是我搞错了：先解锁再发signal是可以的。

你是怎么统计循环次数的？

是不是存在这样一种线程调度的极端情况：你的生产者发完signal后没等消费者获 得执行权就继续执行（获取互斥锁），于是消费者只能再等一个（或n个周期）。 这种情况下，如果在消费者那边统计的循环次数就会比生产者这边少。