继续多进程中CreateMutex与ReleaseMutex使用有关问题

来源:本网整理

cpu CPU属于可剥夺性资源,但一个进程已获得的资源,在未使用完之前,另一个进程要使用可以把它的资源剥夺过来,所以不会产生死锁。只有不可剥夺资源才会因为竞争资源而产生死锁www.zgxue.com防采集请勿采集本网。

继续多进程中CreateMutex与ReleaseMutex使用问题

我前面帖子询问多进程中CreateMutex与ReleaseMutex的问题。

做一下系统 吧 你删了以后重启还会有的要不 要不就装个360试试

http://bbs.csdn.net/topics/390848187?page=1

大致可以这样理解。一般说多线程是指cpu可以多核同时工作。多进程比较常见了,就是电脑可以开多个程序。好比说打日本鬼子。多进程就是打死多个日本鬼子。多线程就是同时那两把机枪打日本鬼子

需要在多进程中使用,互斥锁控制共享内存。

用的可能是早期的版本吧。现在的office2013已经可以多进程运行了,可以试试试用版的。注册现在也不难了,到贴吧里找找就激活了。更多IT知识,可以到 软媒 IT之家 咨询了解。

 hMutex=CreateMutex(NULL,TRUE,“ReadWrite11”);

进程调度的时机与进程特点有关,如进程是否为CPU繁忙型还是I/O繁忙型、自身的优先级等。但是仅这些特点是不够的,能否得到调度还取决于进程调度策略,若采用优先级调度算法,则进程的优先级才起

如果该语句在主进程中,子进程无法ReleaseMutex( hMutex),因为谁创建,谁才能释放。

进程自身和进程调度策略

最后我在子进程A中创建,子进程A自然可以释放,主进程可以waifor该信号。问题来了:

因为有多个子进程,子进程B中用下吗语句得到的是同一个锁,却无法ReleaseMutex( hMutex),

 hMutex=CreateMutex(NULL,TRUE,“ReadWrite11”);

进程调度的时机与进程特点有关,如进程是否为CPU繁忙型还是I/O繁忙型、自身的优先级等。但是仅这些特点是不够的,能否得到调度还取决于进程调度策略,若采用优先级调度算法,则进程的优先级才起

改为OpenMutex同样没有释放权。

那么微软设计的这个互斥根本无法在3个以上进程中使用?

这是多进程,不是多线程。请对多进程有实际经验的朋友指导。

------解决方案--------------------

同名的mutex最多只允许一个thread获取owner。所有不管多少进程或线程在等待同一个mutex, 只有一个允许运行。

按你的例子:一个进程(假设主进程)CreateMutex(NULL, TRUE, “ReadWrite11”)成功,GetLastError==0,那么返回的handle已经被这个进程拥有了,其它进程(不管多少,假设是子进程)同样CreateMutex(NULL, TRUE, “ReadWrite11”),如果成功返回了handle, 并且GetLastError==ERROR_ALREADY_EXISTS,这个进程并不拥有这个mutex, 但是你可以用wait系列函数等待拥有者释放它。此时主进程调用ReleaseMutex释放拥有权,等待的某个进程可以获取这个mutex,如果主进程又一次希望拥有这个mutex,那么主进程可以用wait系列函数等待拥有这个mutex的子进程调用ReleaseMutex。

因此,谁获取了mutex谁负责调用ReleaseMutex,否则其它进程/线程无法再次拥有它。 

CreateMutex后WaitFor.../ReleaseMutex相当于lock/unlock操作。

------解决方案--------------------

每个进程都一样吧

h = OpenMutex(...);

if(h == 0)

h = CreateMutex(...);

......

// todo

ReleaseMutex(...);

有什么问题吗?

------解决方案--------------------

我也一直在关注楼主的这个问题,上个帖子我也跟了。

楼主想做进程间互斥能不能换个思路:

思路1:

是否可以使用两个mutex,例如:进程A创建Mutex为MA,进程B创建Mutex为MB;进程A等待进程B创建的MB,进程B等待进程A创建的MA;让两进程都处于等待状态,当某个时机需要触发时Release MA或MB;

楼主按这个思路想想,可以先解决你的问题。

但感觉还是不太好:

1、多个进程交互起来就有点麻烦了;(通过逻辑处理可以实现)

2、感觉这是一个回避的办法,从本质上根本没解决这个问题;

3、玩不好的话容易出现死锁;

思路2:

不使用mutex,使用Event是否可以代替,在多个进程SetEvent是没有问题的,这个我式过。

------解决方案--------------------

只能说楼主没有好好看msdn上的说明,initowner参数的解释还是很细的

------解决方案--------------------

引用:
这个问题看了很多网页,用了好几天的时间调试追踪,总算解决了,还是《Window 核心编程》解释得比较清楚。

多个进程不同时刻是可以支配同一个mutex的。这里的关键是锁的所有者owner要说清楚:所有者不一定是创建者CreateMutex,而是加锁的进程,什么是加锁的进程?谁waitfor了,谁就加锁,就是该mutex当前的owner,必须由该进程Release。其它进程才能waitfor。关键是每个mutex个实例(object)中有一个数据成员,会记录它的owner。

A进程CreateMutex设置第2个BOOLbInitialOwner, // 初始化互斥对象的所有者,则A相当于加锁,是该mutex当前的owner,释放后,其它进程才可以waitfor。如果CreateMutex第2个参数是false,则任何进程都可以waitfor,并立即成为该mutex的owner。

另外,一个进程如果是某mutex的owner,可以连续多次waitfor该锁,object中有一个成员计数。要注意的是,一次Release是解不开n次加锁的,可能会造成调试中的困扰。

所以呢,网友们的解释总是很模糊,可以是没有实际编程经历,或者是表达能力有问题。

在楼主发的这三个帖中学习到了,给楼主加关注了,很佩服楼主的这种专业精神,值得我学习,不过我还是没能看懂上面话的意思,我再体会体会。

------解决方案--------------------

引用:
这个问题看了很多网页,用了好几天的时间调试追踪,总算解决了,还是《Window 核心编程》解释得比较清楚。

多个进程不同时刻是可以支配同一个mutex的。这里的关键是锁的所有者owner要说清楚:所有者不一定是创建者CreateMutex,而是加锁的进程,什么是加锁的进程?谁waitfor了,谁就加锁,就是该mutex当前的owner,必须由该进程Release。其它进程才能waitfor。关键是每个mutex个实例(object)中有一个数据成员,会记录它的owner。

A进程CreateMutex设置第2个BOOLbInitialOwner, // 初始化互斥对象的所有者,则A相当于加锁,是该mutex当前的owner,释放后,其它进程才可以waitfor。如果CreateMutex第2个参数是false,则任何进程都可以waitfor,并立即成为该mutex的owner。

另外,一个进程如果是某mutex的owner,可以连续多次waitfor该锁,object中有一个成员计数。要注意的是,一次Release是解不开n次加锁的,可能会造成调试中的困扰。

所以呢,网友们的解释总是很模糊,可以是没有实际编程经历,或者是表达能力有问题。

所以还是因为参数的原因影响了谁获取到mutex才造成了一系列问题。

------解决方案--------------------

我总觉得这是理所当然的事,没想到可能有些人理解会出现歧义.

这让我明白一个理:

你认为简单的事,可能对别人是复杂的事.别觉得别人笨,可能只是理解上的一些差别。

你认为复杂的事,可能对别人是简单的事.别觉得自己笨,可能只是理解上的一些差别。

------解决方案--------------------

引用:
Quote: 引用:

同名的mutex最多只允许一个thread获取owner。所有不管多少进程或线程在等待同一个mutex, 只有一个允许运行。

按你的例子:一个进程(假设主进程)CreateMutex(NULL, TRUE, “ReadWrite11”)成功,GetLastError==0,那么返回的handle已经被这个进程拥有了,其它进程(不管多少,假设是子进程)同样CreateMutex(NULL, TRUE, “ReadWrite11”),如果成功返回了handle, 并且GetLastError==ERROR_ALREADY_EXISTS,这个进程并不拥有这个mutex, 但是你可以用wait系列函数等待拥有者释放它。此时主进程调用ReleaseMutex释放拥有权,等待的某个进程可以获取这个mutex,如果主进程又一次希望拥有这个mutex,那么主进程可以用wait系列函数等待拥有这个mutex的子进程调用ReleaseMutex。

因此,谁获取了mutex谁负责调用ReleaseMutex,否则其它进程/线程无法再次拥有它。 

CreateMutex后WaitFor.../ReleaseMutex相当于lock/unlock操作。

这个解释核心是,A进程WaitFor到hMutex之后,A就是拥有者,就是owner。B进程WaitFor到hMutex之后,B就是拥有者,就是owner。必须由该owner来ReleaseMutex(hMutex);

任何进程通过CreateMutex(NULL,0, “ReadWrite11”)都可以WaitFor并ReleaseMutex,不限于创建进程。

创建进程如果CreateMutex如果第2个参数是true,那么就是默认的当前的拥有者,就是owner。否则该锁对任何进程是开放的,就是任何进程都可以Waitfor成为有者,就是owner。

举个生活中的例子。某班A同学买了一把锁用于锁书橱,这把锁只有一个钥匙。他可以立即锁上(CreateMutex如果第2个参数是true),成为当时的owner(钥匙保管人)。也可以不立即锁上(CreateMutex如果第2个参数是false),把锁和钥匙放在教室里,任何人需要就可以使用。

此后,谁锁上,钥匙就在谁手上,成为 owner,必须由此人开锁(Release),交出钥匙,其它人才可以再锁上,并成为 owner。

例子举得很到位,不过还有点问题请指教一下。

就是说第一个waitfor的为owner,那么如果owner不释放的话,那么其他waitfor的进程装会永远处于等待状态是吧?

------解决方案--------------------

引用:
Quote: 引用:

Quote: 引用:

同名的mutex最多只允许一个thread获取owner。所有不管多少进程或线程在等待同一个mutex, 只有一个允许运行。

按你的例子:一个进程(假设主进程)CreateMutex(NULL, TRUE, “ReadWrite11”)成功,GetLastError==0,那么返回的handle已经被这个进程拥有了,其它进程(不管多少,假设是子进程)同样CreateMutex(NULL, TRUE, “ReadWrite11”),如果成功返回了handle, 并且GetLastError==ERROR_ALREADY_EXISTS,这个进程并不拥有这个mutex, 但是你可以用wait系列函数等待拥有者释放它。此时主进程调用ReleaseMutex释放拥有权,等待的某个进程可以获取这个mutex,如果主进程又一次希望拥有这个mutex,那么主进程可以用wait系列函数等待拥有这个mutex的子进程调用ReleaseMutex。

因此,谁获取了mutex谁负责调用ReleaseMutex,否则其它进程/线程无法再次拥有它。 

CreateMutex后WaitFor.../ReleaseMutex相当于lock/unlock操作。 c_a_3();

这个解释核心是,A进程WaitFor到hMutex之后,A就是拥有者,就是owner。B进程WaitFor到hMutex之后,B就是拥有者,就是owner。必须由该owner来ReleaseMutex(hMutex);

任何进程通过CreateMutex(NULL,0, “ReadWrite11”)都可以WaitFor并ReleaseMutex,不限于创建进程。

创建进程如果CreateMutex如果第2个参数是true,那么就是默认的当前的拥有者,就是owner。否则该锁对任何进程是开放的,就是任何进程都可以Waitfor成为有者,就是owner。

举个生活中的例子。某班A同学买了一把锁用于锁书橱,这把锁只有一个钥匙。他可以立即锁上(CreateMutex如果第2个参数是true),成为当时的owner(钥匙保管人)。也可以不立即锁上(CreateMutex如果第2个参数是false),把锁和钥匙放在教室里,任何人需要就可以使用。

此后,谁锁上,钥匙就在谁手上,成为 owner,必须由此人开锁(Release),交出钥匙,其它人才可以再锁上,并成为 owner。

例子举得很到位,不过还有点问题请指教一下。

就是说第一个waitfor的为owner,那么如果owner不释放的话,那么其他waitfor的进程装会永远处于等待状态是吧?

如果owner所在线程结束,这个mutex会自动释放。除此之外除非拥有的线程调用ReleaseMutex,否则其它线程必须等待,waitfor...不会返回

一般运行一个程序称为一个进程。进程可以创建线程,也可以创建进程。线程是由进程管理的,线程之间、线程和父进程(创建线程的进程)之间可以共享内存变量(需要使用策略的)。进程之间一般不可以直接共享内存变量,需要使用一些进程间的控制共享内存变量。如果你使用并行计算,建议使用线程内容来自www.zgxue.com请勿采集。

免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 帮助中心 - 频道导航
Copyright © 2017 www.zgxue.com All Rights Reserved