OS X 上奇怪/不正确的 sem_getvalue 信号量行为
我有一些非常基本的信号量代码,在 Linux 上运行得很好,但我一生都无法让它在 OS X 上正常运行...它返回最奇怪的结果...
#include <iostream>
#include <fcntl.h>
#include <stdio.h>
#include <semaphore.h>
int main()
{
sem_t* test;
test = sem_open("test", O_CREAT, 0, 1);
int value;
sem_getvalue(test, &value);
printf("Semaphore initialized to %d\n", value);
}
在 OS X 上使用 g++ 编译它会返回以下结果输出:
iQudsi:Desktop mqudsi$ g++ test.cpp
iQudsi:Desktop mqudsi$ ./a.out
Semaphore initialized to -1881139893
而在 Ubuntu 上,我得到了明显更理智的结果:
iQudsi: Desktop mqudsi$ g++ test.cpp -lrt
iQudsi:Desktop mqudsi$ ./a.out
Semaphore initialized to 1
我已经连续 3 个小时这样做了,并且无法弄清楚为什么 OS X 返回如此奇怪的结果......
我尝试使用文件路径作为信号量名称,没有什么区别。
如果我能得到任何帮助,我将不胜感激。
I have some very basic semaphore code that works great on Linux, but cannot for the life of me get it to run properly on OS X... It returns the oddest of results...
#include <iostream>
#include <fcntl.h>
#include <stdio.h>
#include <semaphore.h>
int main()
{
sem_t* test;
test = sem_open("test", O_CREAT, 0, 1);
int value;
sem_getvalue(test, &value);
printf("Semaphore initialized to %d\n", value);
}
Compiling this on OS X with g++ returns the following output:
iQudsi:Desktop mqudsi$ g++ test.cpp
iQudsi:Desktop mqudsi$ ./a.out
Semaphore initialized to -1881139893
Whereas on Ubuntu, I get the decidedly more-sane result:
iQudsi: Desktop mqudsi$ g++ test.cpp -lrt
iQudsi:Desktop mqudsi$ ./a.out
Semaphore initialized to 1
I've been at this for 3 hours straight, and cannot figure out why OS X is returning such bizarre results...
I've tried using file paths as the semaphore name, it didn't make a difference.
I'd appreciate any help I could get.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您正在测试错误吗? 尝试:
Are you testing for errors? Try:
您正在使用Mac OS X中当前未实现的函数,并且您正在打印的整数包含初始化该整数的默认数据,该数据可能是仍在内存中的随机数据。 如果您将其清零,通过将其设置为
int value = 0;
,您可能会更快地发现此错误。这是我使用的代码(感谢 bdonlan ):
You are using a function that is not currently implemented in Mac OS X, and the integer you are printing out contains the default data that the integer was initialised with which was probably random data that was still in memory. Had you zero'd it out, by setting it with
int value = 0;
you might have caught this mistake sooner.This is the code I used (thanks to bdonlan):
好吧,也许 sem_open() 失败了——你没有测试。
或者,也许 OSX 并不默认支持共享 posix sems - 如果未安装 /dev/shm,通常系统将不支持 sem_open()。
您可能想要使用 SysV 信号量。
这里提出了有关 Slackware 的类似问题:how-do-i-stop -semopen-failing-with-enosys
然而,进一步搜索显示 OSX 命名信号量是在 Mach 信号量之上构建的,完成后您可能需要 sem_unlink() 它们(不仅仅是 sem_close(),或者也许相反),并且您应该小心权限 - 我建议从 0777 或可能 0700 开始,而不是 0。请参阅 达尔文中的 posiz 信号量
Well, perhaps sem_open() is failing - you didn't test.
Or, perhaps OSX doesn't default to supporting shared posix sems - if /dev/shm isn't mounted, typically the system won't support sem_open().
You may want to use SysV semaphores.
A similar question regarding Slackware was asked here: how-do-i-stop-semopen-failing-with-enosys
However, further searching shows OSX named semaphones are built on top of Mach semaphores, and you probably need to sem_unlink() them when you're done (not just sem_close(), or maybe instead), and you should be careful about permissions - I suggest starting with 0777 or maybe 0700, instead of 0. See posiz semaphores in Darwin