Linux 线程同步问题。

[pottichu]

1. pthread_mutex_t 是否与 Windows 的 Mutex 一样的低效？

2. pthread_cond_t
当A, B 线程中调用 pthread_cond_wait 以后，
C 线程调用 pthread_cond_signal， 则只有一个线程被激活，并且只能执行一次，
若C 线程调用的是 pthread_cond_broadcast 则两个线程都被激活，并且各执行一次。
问题是， Linux 中能实现 象 Windows 中的 Event 一样的效果吗？

3. 信号量， 感觉这个和 Windows 下的差不多，用的也不多，就不提了。

4. 也是关键问题， linux 中用什么方法加锁的效率比较高 ？ Windows 中 能用 CRITICAL_SECTION
Linux 中呢？ pthread_cond_t 类似与 Event不合适， Mutex 效率又似乎太低。 怎么办？

[pottichu]

linux 版，问个问题几天都没人回，也就不去了。
C++ 版熟人多，呵呵。 1 楼的朋友就挺眼熟的。
我的关键问题是 pthread_mutex_t 对象的效率问题。
lngf(般若) 说的 QT 有封装，封装也会用到底层的东西啊。
再说我做的东西没界面的... :(， 提供 API给别人用。

[taodm]

呃，linux不熟。不过，mutex什么的，慢也要用呀。

[pottichu]

查了半天， pthread_mutex_t 的速度虽然比不了 CRITICAL_SECTION, 但比 Windows 的 Mutex 还是要快很多的。
看来也没有别的选择了。似乎 Linux 的线程切换速度也不如 Windows.

[珍惜生命远离CPP]

线程的话还是用pthread_mutex_t吧
反正Linux对线程支持不好，进程通讯比较方便

[jixingzhong]

.....

[仰望星空WU]

pthread_mutex_t 是那种一进程一线程的那种线程机制，在内核中进程线程的调试是同级别的，因此linux的线程比window下的线程高效

[pottichu]

星辰老大为什么.......................?

[bournechen]

linux内核中实际上没有线程的概念，不管是线程还是进程都是分配进程id号，唯一一点不同就是进程有独立的用户空间而线程是与fork（）其的父进程用相同的用户空间

[pottichu]

谢谢 taodm(taodm) 的提醒。
刚才看了一下 Boost 和 ACE 中的 Mutex 类。失望ing。。
无非是对 CRITICAL_SECTION 和 pthead_mutex_t 的封装而已。
我担心的是 对 pthead_mutex_t 加锁，导致资源分配并不平等，
Windows 下的 CRITICAL_SECTION 就完全没有问题。

[fiftymetre]

不管是在UNIX或是LINUX中都不推荐用线程 的吧。

[pottichu]

但， 对于网络程序， 还是比较需要线程的啊.
难道换多进程吗 ?

[tb01412]

不用pthead_mutex_t 加锁，那你用什么？？？？？
除非你对内核加个补丁，你自己去实现一个线程锁，然后提供给自己使用，如果你能写出比现的还要高效且安全的话，你已经是高手了！！！
WINDOWS中是一进程多线程的方式，而LINUX是在内核级把线程当作一个进程来看待，当你锁住一个变量时，如果这个锁已被占用，那么当前线程就会休眠，然后调度别的线程（进程），而LINUX是采用写时拷贝技术与物理页共享计数方式，对于一个进程中被多个线程共同使用的变量，使用了内核的共享物理内存页技术，也就是说这种方式的效率已经够快了，如果你用进程通讯的话（会用到写时拷贝），效率更低（比如信号量），真不懂你所说的采用线程锁的方式导致效率低是什么意思？？？？？LINUX下的效率损失主要是线程库的实现开销，由于LINUX在内核中一个进程模拟一个线程，所以用户层的线程库需要做很多同步工作，如果你想得到更高的效率，你可以在内核中加入向用户层提供的原子操作函数，提供给用户调用，比如内核中加入自己的lock，unlock系统调用，这样可以初步达到你的需求

[pottichu]

楼上的朋友说话怎么这么大火气,呵呵。
pthread_mutex_t 效率不高这是事实.
我是在询问" pthread_mutex_t 会不会比较低效 " 请看清楚.
最后,我查阅的结果是别无选择.

还有回答问题前请看清楚前面的回复.
我担心的是 对 pthead_mutex_t 加锁，导致资源分配并不平等
请看看我前面的代码.
至于代码中没有
pthread_join(&tid1, NULL);
pthread_mutex_distroy(&mutex);
就不要提了。

[pottichu]

up.....

[yufengchen927]

up

[shawnwan]

在linux系统调用中，确实是非常的难用
并且linux起初是不支持线程的，只有子进程的概念

在实际工作中，我们通常不会直接用linux系统调用

而采用QT的库，线程用QThread,进程间通信用QCopChannal
它完全封装了C++标准库和部分Linux系统调用，是很高效的

[pottichu]

哎,我也知道 Boost, ACE 都封装了能跨平台的 线程库.
但我的东西是要跑在嵌入式 Linux 上的. 根本用不了这些大型库啊..

[yufengchen927]

up

[pottichu]

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

pthread_mutex_t mutex;

void * child1(void *arg)
{
while(1)
{
printf("thread 1 pthread_mutex_lock returns %d\n", pthread_mutex_lock(&mutex));
sleep(1);
printf("thread1 pthread_mutex_unLock returns %d\n", pthread_mutex_unlock(&mutex));
}
}

void *child2(void *arg)
{
while(1)
{
printf("thread 2 pthread_mutex_lock returns %d\n", pthread_mutex_lock(&mutex));
sleep(1);
printf("thread1 pthread_mutex_unLock returns %d\n", pthread_mutex_unlock(&mutex));
}
}

int main(void)
{
int tid1,tid2;
printf("hello, condition variable test\n");
pthread_mutex_init(&mutex,NULL);
pthread_create(&tid1,NULL,child1,NULL);
pthread_create(&tid2,NULL,child2,NULL);
sleep(100);
pthread_exit(0);
}


互斥锁的属性在创建锁的时候指定，在LinuxThreads实现中仅有一个锁类型属性，不同的锁类型在试图对一个已经被锁定的互斥锁加锁时表现不同。当前（glibc2.2.3,linuxthreads0.9）有四个值可供选择：

PTHREAD_MUTEX_TIMED_NP，这是缺省值，也就是普通锁。当一个线程加锁以后，其余请求锁的线程将形成一个等待队列，并在解锁后按优先级获得锁。这种锁策略保证了资源分配的公平性。

但事实是并未排队， 总是线程1 在执行， 这到底是怎么回事？
线程1 先启动，并 lock了 mutex， 然后 sleep ，
线程2 的 lock 等待，
线程1 unlock
这时候应该是 线程 2 lock 并执行啊。
为什么总是 线程1 在执行？ 难道不是在排队?

[taodm]

楼主，你把ACE或者BOOST抄一段出来就可以嘛。