|
|
1
4
哦。。。不,不,不。 这里不应该用线。 说真的。在这种情况下,线程不是您的解决方案。让我们往后退一点。。。
停下来问问你自己- 您确定这些操作需要从OpenGL呈现异步(作为一个整体)完成吗? 如果是这样的话,您可能会停止阅读本文并查看其他文章,但我真诚地相信,对于典型的+实时OpenGL应用程序,情况可能并非如此。 所以。。。典型的OpenGL应用程序如下所示:
大多数GL窗口库允许您将其实现为自己的主循环,GLUT会用它的“回调”来混淆它,但其思想是相同的。 您仍然可以在应用程序中引入并行性,但它应该在步骤2开始和停止,因此它在主循环级别上仍然是连续的:“计算一帧计算,然后呈现此帧”。这种方法很可能 省去你很多麻烦 . 普罗蒂普:换你的图书馆。供过于求是过时的,不再维持了。切换到GLFW(或SDL)来创建窗口在代码方面不需要太多的努力,而且-与GLUT相反-您可以自己定义主循环,这似乎是您希望在这里实现的。(此外,它们往往更便于输入和窗口事件处理等) 一些具有恒定时间步的典型伪代码实时物理,而不干扰渲染(假设您希望比渲染更频繁地运行物理):
可能的扩展是使用
|
|
|
2
1
在主线程中:锁定互斥锁,将包含必要信息的结构/对象添加到某种FIFO数据结构中,解锁互斥锁,然后(可选)唤醒后台线程(通过信号或条件变量,或将字节写入套接字,或无论如何) 在后台线程中:(可选)阻塞直到被主线程唤醒,然后锁定互斥锁,从FIFO头弹出第一个项目,解锁互斥锁,处理该项目,重复。 |
|
3
1
关键部分和互斥体不好。它们应该只被库设计人员使用,而且通常不会被使用(因为对于可重用代码来说,获得无锁的额外可伸缩性通常是值得的)。 相反,您应该使用线程安全队列。Windows提供了很多:
只是你的一些选择。 所有这些都是高度优化的,比设计自己的队列更容易使用。 |
|
|
4
1
我不建议再使用过剩-这是非常过时和限制性的。但如果你开始使用它,你可能会想调查一下 glutIdleFunc . 当这个回调空闲时,GLUT将继续调用它——您可以使用它在主线程中执行后台处理。 |