C++ 项目中共享模型的多线程同步

我现在正在写一个多线程应用程序（确切地说是游戏），作为一个爱好/研究项目。我最近遇到了一个非常“简单”的问题，那就是在线程之间进行同步（如果这对您很重要，那么它是用c++实现的）

我的主要问题是——我试图学习好的设计，并尽可能地将我的整个模型静音，这（在我看来）是浪费资源的，而且只是在进一步的开发中提出问题。我曾考虑过让整个同步过程基于事务，但我觉得它不适合游戏类型所需的性能/可扩展性。我是并发编程新手，我来这里是为了学习一些关于并发编程特定模式的新知识

关于当前设计的几句话：

• MVC方法
• 在线同步由一个单独的代理处理，该代理在从属客户端和主服务器上相同，并且与任何服务器逻辑分开处理
• 类似数据库的结构正在与服务器逻辑不依赖地同步，并且内置了一些较小的订阅/观察者模式，以通知控制器有关更改

注释

• 我不寻找特定于文档的信息（如果它们与性能或设计没有直接联系），我知道我的

  cppreference

• 我确实在寻找一些广泛的博客/网站，它们可以教我更多关于并行设计模式的知识
• 我真的想知道我是否只是在做错事（但不是按错误的顺序）

编辑

正如Mike提到的，我没有问这个问题：

1） 在并发编程中可以使用的最佳设计模式/规范是什么（在我的例子中，大多数是可用的）

---

2） 在并发编程性能方面，最大的禁忌是什么

你的想法有点错误。并行性关乎性能，并发性关乎正确性。并发系统不一定是最快的解决方案。一个好的并发系统最小化并明确定义依赖关系；以最小的延迟实现一个健壮、反应迅速的系统。相比之下，并行系统通过最大限度地利用资源来尽量减少执行时间；这样做可能会使延迟最大化。虽然有重叠，但心态却大不相同

有许多好的并发语言。C++不是其中之一。也就是说，您可以用任何语言编写良好的并发系统。大多数并发语言都有很强的消息传递倾向，但是大多数语言都有很好的消息传递库

消息传递不同于低级同步机制，因为它本身就是一种模型或思维方式。互斥体、信号量等。。。不是。它们是工具，在设计合理完成之前，可能会被忽略

---

设计阶段应该比同步机制更抽象。理想情况下，它应该筛选出操作（或事务，如果您愿意）以及它们之间必要的交互。根据该模式，关于如何安排并发访问的数据和代码的选择应该是自然的。如果不是，则说明您的模式不完整。

Hmm，如果不知道您正在对代码的哪些部分进行静音，很难判断。只是模型、视图和控制器之间的交互，还是有更多线程同时访问数据？对于MVC部分，您可以查看活动对象模式或命令模式，它们将方法执行与其调用分离。我在对象上使用decorator模式，因为我使用Flatbuffers序列化数据。我为每个对象添加了一个mutator/accessor装饰器，并在其中对其进行了静音。至于现在（工作并没有进展到那个程度，因为我注意到很多代码的味道，比如大量的互斥和与之相关的可重复逻辑）。接下来，我确定我有一个网络管理器，它从套接字管理器收集数据，并尝试将其放入信息模型中。然后是服务器控制器，它们做自己的事情（如寻路、勾号处理等），然后尝试更新info-model。我的主要问题是，如何处理服务器工作，以避免遇到典型的比赛或处理未更新的数据。好吧，虽然我同意你的观点，但我还是花了不少时间，用反汇编测试我的代码，不知怎么回答了我的问题。不幸的是，即使你的回答是朝着好的方向发展，我也不认为它回答了我的问题。虽然对我来说，

parallelism

和

concurrency

以一种非常容易理解的方式呈现，但我还是要感谢您！