多线程会影响康威的生命游戏克隆吗?

发布于 2024-09-10 11:51:08 字数 317 浏览 10 评论 0 原文

我一直在实现这个小游戏的想法,它(以某种方式?)类似于康威的生命游戏:

0)你有一个彩色点矩阵(RGB值) 1) 如果相邻单元格的 X 值低于 Y 值,则在该单元格上设置 Y = 0 (其中 X 和 Y 为红色 || 绿色 || 蓝色) 2)红色击败绿色击败蓝色击败红色

我现在所做的只是逐个单元检查是否满足上述规则。但是,这种行为并不完全符合我的预期,因为有时第一行上的单元格比末尾行上的单元格具有优势。

多线程可以防止这种情况(例如,启动两个线程,一个在第一个单元中启动,另一个在最后一个单元中启动)?请原谅我对并发的无知,但我觉得这是开始使用并发的好方法。

I've been implementing this little game idea, which is (somehow?) similar to Conway's Game of Life:

0) You have a matrix of colored dots (RGB values)
1) If the adjacent cell has a lower X value than your Y, put Y = 0 on that cell
(Where X and Y are Red || Green || Blue)
2) Red beats Green beats Blue beats Red

What I'm doing now it's just going cell by cell, checking if the above rules are met. However, the behavior it's not quite what I intended since sometimes cells on the first rows have advantage over those at the ending rows.

Can multithreading prevent this (say, launching two threads, one initiating in the first cell and the other on the last one)? Please pardon my ignorance on concurrency, but I felt this was a nice way to begin working with it.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

无悔心 2024-09-17 11:51:08

我的猜测是,您正在就地更新矩阵,而您应该复制跟踪矩阵的旧状态,更新新状态,然后用更新后的状态替换原始状态。
这样,您就不会更新某些单元格,然后在下一行测试它们的值。
因此,这将是一个算法问题,与编程无关(因此多线程无济于事)。

My guess is that you are updating the matrix inplace, whereas you should copy keep a track of the old state of the matrix, updating a new one, then replacing the original one by the updated.
This way, you won't update some cells, then on the next line test their values.
Thus, it would be an algorithm problem, not related with programmation (and therefore multithreading cannot help).

來不及說愛妳 2024-09-17 11:51:08

不,你的问题是一个固有的缺陷。您遇到的问题是您正在使用中间结果,即在此更新中,一个单元格中的更改会立即影响下一个单元格。不应该。您应该创建一个新矩阵,将更改后的值存储在其中,然后交换它们以便加载新值。重复。

No. Your problem is an inherent flaw. The trouble that you have is that you're using intermediate results, i.e., the change in one cell affects the next cell immediately, in this update. It shouldn't. You should create a new matrix, store the changed values in there, and then swap them so that the new values are loaded. Repeat.

一场信仰旅途 2024-09-17 11:51:08

你最好调整你的算法来防止这种情况发生。

依靠多线程来改变行为并不是一件好事。本质上,这是试图在代码中引入竞争条件。通常,当向算法添加多线程时,首要任务是防止行为发生任何变化。

通过尝试使用竞争条件来改变行为,你会使其变得非常不确定,但不是以一种好的方式。您最好尝试为此提出不同的解决方案(可能使用伪随机数生成器等),然后引入多线程以使其更快(希望不会影响结果)。

You'll be better off adapting your algorithm to prevent this.

Relying on multithreading to change behavior is not a good thing. This is, in essence, trying to introduce a race condition into your code. Normally, when adding multi-threading to an algorithm, the first priority is to prevent any changes in behavior.

By trying to use a race condition to change behavior, you're making this very non-deterministic, but not in a good way. You'd be much better off trying to come up with a different solution to this (potentially using a pseudo-random number generator, etc), and then introducing multi-threading to make it faster (hopefully without affecting the results).

渔村楼浪 2024-09-17 11:51:08

这取决于您选择多线程处理的哪一部分。 原型 多线程的例子是矩阵乘法器。您基本上可以将其分解为象限并在每个线程中计算一个象限,除了原始矩阵之外不共享信息。请注意,生命游戏是一个稀疏矩阵,并且 可能会也可能不会从多线程中受益。

但是,如果您决定这样做,请记住,一切都应该计算“下一轮”所需的内容,并将其放入新的矩阵中,当交换矩阵时(最好不要复制,只需更改指针某处)在回合结束时,这样一个线程就不会改变其他线程进行计算所需的值。因此,不能允许线程彼此“领先”。这可能意味着使用多个线程的效率很低——您的里程可能会有所不同。

It depends on what part of the processing you choose to multithread. The prototypical multithreading example is the matrix multiplier. You can basically break it up into quadrants and calculate one quadrant in each thread, with no sharing of information except the original matrix. Note that the Game of Life is a sparse matrix, though, and may or may not benefit from multithreading.

However, if you do decide to do so, keep in mind that everything should calculate what it needs to for the "next turn" and place it in a new matrix, when swap-in the matrix (preferrably not copy, just change a pointer someplace) at the end of the turn, so that one thread isn't changing the values that the other ones need to do their calculations. So the thread's can't be allowed to "get a turn ahead" of each other. This might mean that it turns out to be inefficient to do with multiple threads - your mileage may vary.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文