关于OpenMutex 和 CreateMutex 的使用问题

hzy694358 2010-12-25 11:27:39
第一次创建:
CreateMutex(NULL,TRUE,_T("TEST));

接下来我在其他的进程中想使用该互斥量来同步
那么我应该使用OpenMutex(MUTEX_ALL_ACCESS,FALSE,T("TEST")) 来获取_这个互斥量
还是依然调用第一次创建:CreateMutex(NULL,TRUE,_T("TEST));
备注:看文档说明,貌似都可以。

这两种方式返回的句柄,CloseHandle是否能有效的释放这个互斥量呢?

...全文
5482 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
向立天 2010-12-27
  • 打赏
  • 举报
回复 1
[Quote=引用 9 楼 hzy694358 的回复:]
引用 8 楼 xianglitian 的回复:

如果互斥对象以存在OpenMutex和CreateMutex返回的句柄肯定是一样的
这个也很容测试出来
这个哥函数最大的区别是
如果互斥对象不存在
OpenMutex不会创建新对象而CreateMutex会
有的时候我们只是想看看有没有一个互斥对象存在而不想创建它
这个时候只能用OpenMutex

那根据返回的句柄CloseH……
[/Quote]
这个我也不是特别了解
看看其他朋友怎么说吧
arong1234 2010-12-25
  • 打赏
  • 举报
回复
看你目的,如果你要确保打开一个现有的Mutex,需要用Open,如果你不关心这是不是现有的,Create总是可以的

ClonseHandle当然可以关闭
羽飞 2010-12-25
  • 打赏
  • 举报
回复
关注,
hzy694358 2010-12-25
  • 打赏
  • 举报
回复
[Quote=引用 8 楼 xianglitian 的回复:]

如果互斥对象以存在OpenMutex和CreateMutex返回的句柄肯定是一样的
这个也很容测试出来
这个哥函数最大的区别是
如果互斥对象不存在
OpenMutex不会创建新对象而CreateMutex会
有的时候我们只是想看看有没有一个互斥对象存在而不想创建它
这个时候只能用OpenMutex
[/Quote]
那根据返回的句柄CloseHandle的话,能关闭那个互斥量吗
怎么资料有的说,OpenMutex返回的句柄并不能关闭互斥量呢,
bInitialOwner
Boolean that specifies the initial owner of the mutex object. If this value is TRUE and the caller created the mutex, the calling thread obtains ownership of the mutex object. Otherwise, the calling thread does not obtain ownership of the mutex. To determine if the caller created the mutex, see the Return Values section.
或者是把CreateMutex的函数第二个参数设置为FALSE,OpenMutex才能真正的CloseHandle互斥量句柄
向立天 2010-12-25
  • 打赏
  • 举报
回复
如果互斥对象以存在OpenMutex和CreateMutex返回的句柄肯定是一样的
这个也很容测试出来
这个哥函数最大的区别是
如果互斥对象不存在
OpenMutex不会创建新对象而CreateMutex会
有的时候我们只是想看看有没有一个互斥对象存在而不想创建它
这个时候只能用OpenMutex
hzy694358 2010-12-25
  • 打赏
  • 举报
回复
你不能因为你这里有不到OpenMutex就说它没有存在的必要对吧
-------------------------------------------------------
这也是我发这个贴的原因,我就是想知道答案
如果CreateMutex 也能返回已经存在的互斥量句柄,那么OpenMutex存在的意义是什么
或者说有什么区别于CreateMutex 的地方?
如果互斥量已经存在的话,那么OpenMutex 和 CreateMutex 返回的句柄一样的吗?
向立天 2010-12-25
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 hzy694358 的回复:]
引用 2 楼 arong1234 的回复:

看你目的,如果你要确保打开一个现有的Mutex,需要用Open,如果你不关心这是不是现有的,Create总是可以的

ClonseHandle当然可以关闭

我是要打开现有的,但是CreateMutex也说了,如果原来已经存在了,那么再次调用的话,会返回已经存在的对象的句柄……
如果是这样的话,那么OpenMutex就感觉没有意义了,我直……
[/Quote]
从设计完整性来说OpenMutex肯定是有必要存在的
从设计健壮性来说CreateMutex具有OpenMutex的功能也是合情合理的
你不能因为你这里有不到OpenMutex就说它没有存在的必要对吧
hzy694358 2010-12-25
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 arong1234 的回复:]

看你目的,如果你要确保打开一个现有的Mutex,需要用Open,如果你不关心这是不是现有的,Create总是可以的

ClonseHandle当然可以关闭
[/Quote]
我是要打开现有的,但是CreateMutex也说了,如果原来已经存在了,那么再次调用的话,会返回已经存在的对象的句柄……
如果是这样的话,那么OpenMutex就感觉没有意义了,我直接都用CreateMutex不就可以了吗,为什么还要OpenMutex
hzy694358 2010-12-25
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 zzdmfk 的回复:]

不要都用createmutex,如果本身存在,会出现Alreadyexsit错误,不可能获得到句柄。一般情况下都是在其他地址空间中用OpenMutex打开的。要不你就不创建命名的Mutex.因为OpenMutex是通过名字打开。
[/Quote]
说明是这样的:

A handle to the mutex object indicates success. If the named mutex object existed before the function call, the function returns a handle to the existing object and GetLastError returns ERROR_ALREADY_EXISTS. Otherwise, the caller created the mutex. NULL indicates failure. To get extended error information, call GetLastError.

也就是说,如果原来已经存在,返回依然是正确的句柄,只是你调用GetLastError 可以得到ERROR_ALREADY_EXISTS
路人乙2019 2010-12-25
  • 打赏
  • 举报
回复
不要都用createmutex,如果本身存在,会出现Alreadyexsit错误,不可能获得到句柄。一般情况下都是在其他地址空间中用OpenMutex打开的。要不你就不创建命名的Mutex.因为OpenMutex是通过名字打开。
在Windows 2000/XP环境下,使用多线程和信号量机制实现经典的读者写者问题,每个线程代表一个读者或一个写者。每个线程按相应测试数据文件的要求,进行读写操作。请用信号量机制分别实现读者优先和写者优先的读者-写者问题。 读者-写者问题的读写操作限制: (1)写-写互斥,即不能有两个写者同时进行写操作 (2)读-写互斥,即不能同时有一个读者在读,同时却有一个写者在写 (3)读-读允许,即可以有二个以上的读者同时读 读者优先的附加限制:如果一个读者申请进行读操作时已有另一读者正在进行读操作,则该读者可直接开始读操作。 写者优先的附加限制:如果一个读者申请进行读操作时已有另一写者在等待访问共享资源,则该读者必须等到没有写者处于等待状态后才能开始读操作。 运行结果显示要求:要求在每个线程创建、发出读写操作申请、开始读写操作和结束读写操作时分别显示一行提示信息,以确信所有处理都遵守相应的读写操作限制。 3 测试数据文件格式 测试数据文件包括n 行测试数据,分别描述创建的n 个线程是读者还是写者,以及读写操作的开始时间和持续时间。每行测试数据包括四个字段,各字段间用空格分隔。第一字段为一个正整数,表示线程序号。第二字段表示相应线程角色,R 表示读者是,W 表示写者。第三字段为一个正数,表示读写操作的开始时间。线程创建后,延时相应时间(单位为秒)后发出对共享资源的读写申请。第四字段为一个正数,表示读写操作的持续时间。当线程读写申请成功后,开始对共享资源的读写操作,该操作持续相应时间后结束,并释放共享资源。下面是一个测试数据文件的例子: 1 R 3 5 2 W 4 5 3 R 5 2 4 R 6 5 5 W 5.1 3

16,550

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Creator Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧