感觉现在的互斥锁不是真正意义上的锁住数据不让其他线程访问。

iw1210

感觉现在的互斥锁不是真正意义上的锁住数据不让其他线程访问。

假设两个线程A和B，要锁的数据是： int  D;

现在锁的意思很简单，只是“我现在用这个锁呢，别人想用就在那等我用完吧”，A线程和B线程都要有这样的表达：

pthread_mutex_lock(&mutex);
操作数据D...
pthread_mutex_unlock (&mutex);


真正锁的意义应该是“我现在正使用这些数据，别人想访问这些数据，等我不用了再给你”。
比如A线程这样锁住数据D后：
Lock{D};    // 注意是花括号不是圆括号

B线程里即使只有一条执行语句：
D = 9;
也实现了锁住D的功能。因为前面A已经把D锁住了，B执行到这条语句时不能继续，只能等A执行：
Unlock{D};
把D解锁后才能继续。

是不是这样的锁更好些呢？ 抛砖引玉～～～

windoze

回复 1# iw1210

Java的synchronize不就是这样么？为什么一定要OS实现这个功能？

iw1210

windoze 发表于 2013-01-21 18:26
回复 1# iw1210

Java的synchronize不就是这样么？为什么一定要OS实现这个功能？

OS实现不更好么？这样用户对锁能更好理解些，使用也方便了

folklore

这个好困难，OS也搞不定啊，
要CPU锁住总线（总线控制器）对某地址的访问才行，
此外，如果一两个还好说，成千上百个可如何锁啊

folklore

@windoze
java是因为它是解释的，所以很容易实现Mutex，
但很多原生的语言要CPU支持的，ｊａｖａ不能什么都搞定阿

windoze

的确，OS能锁内存，但是需要锁住的不止是内存，而是这段内存所代表的资源。
这个资源搞不好是程序自定义的，也不一定就全放在某段内存里，比如说一个指针指向别的什么地方、一个下标指向某个全局数组里的某个元素……
在这种情况下，OS有天大的本领也帮不了你