mutex花消太大了,有没有其它保持原子性操作的方法?

hzhq1

在montavista的linux中,
两线程用同一mutex保证对公共资源的访问,
但发现mutex释放后,
原来等待的线程(B)要一段时间才能重新唤醒.

原申请mutex的线程(A)又重新申请了mutex资源,
结果线程B唤醒后,
又发现mutex已被A占用,
....

所以B继续睡觉...
呵呵

是mutex释放的时间太长?
还是唤醒线程的时间太长?

linux有关中断然后进入临界区的方法吗?

sjinny

这个……我也为这种事头疼中……
不过我觉得多线程技术还是少用好，用的话最好在设计时就减少访问mutex的可能，这样即使偶尔用一下效率低了问题也不大。

hzhq1

手头上的monavista版的linux和标准linux有差别,
我只拿到了OS和驱动的二进制码.

在PC上的RH9,
多线程调用write/ioctl,
无需加MUTEX.

可是在MIPS平台上的monavista,
测试发现竟然在ioctl()函数要加MUTEX才能保证驱动程序正确处理IOCTL.

呵呵,
头晕中.

hzhq1

多谢sjinny!

kakuyou

按照标准来说，ioctl应该是原子的，看来是monavista的实现问题。

我不清楚monavista的线程是怎么实现的，因为现在有两种线程实现方案，一种
是靠内核，一种由用户进程自己实现线程，你在楼顶的问题也许可以通过A在
释放mutex后，usleep(0)或者sleep(0)一下，通过系统调用通知内核进行上下文
切换。

hzhq1

好,
我试试看.

hzhq1

前两天忙着处理DMA错误的事,
今天试着在unlock_mutex()之后加上sleep(0)/usleep(0),
呵呵,
程序竟然睡着了

停在那不动了.

bxu2000

red hat linux下没有这个问题吧，sleep好象是线程安全的
如果是出现sleep使得进程睡眠，应该可以使用select函数解决。

lz的mutex释放是什么意思？是不是unlock呀？
难道不是当unlock后排队在第一的线程首先获取mutex吗？
如果不是我就惨了，现在正在写一个通信处理程序，用了线程，没用进程

hzhq1

X86平台上redhat 7.3/9下一点问题都没有...