User interface GUI并发

防止用户被这种“竞争条件”所迷惑的最佳方法是什么

这可能是一个非常愚蠢的问题

一个GUI，带有一个支持鼠标操作该窗口中对象的窗口。 例如，用户可以从A->B移动、推送等对象。 （这将对几个服务器产生影响，因此这是一个简单的操作，耗电量很大） 如果另一个用户已经对该对象执行了操作，服务器将处理冲突和合并等。 但我们的原始用户必须得到某种反馈，因为这可能同时发生。 （即，用户在一个线程中移动对象，应用程序recv通知在另一个线程中移动）

这与代码无关，即使有人认为recv线程类似于后端存储，并且在进行鼠标推/拖操作时，GUI可能是一个“锁”

你们认为你们把物体放在了B上，但实际上它出现在了B'，B'，C，D（或者消失了）

我一点也不喜欢MessageBox，甚至不可能为每一件小事都弹出一个MessageBox。 不，当用户开始拖动对象时，不能将其锁定给用户

---

也许可以使用一些动画，让用户看到对象落在B上，然后移动、动画到B'，B''、C或D（或蒸发）。

我同意，当并发发生时，您不想在GUI中锁定（或显示模式消息）。我认为，当用户不知道为什么会发生这种情况时，这会让他们感到非常沮丧

我认为保持GUI的响应性（就像没有并发一样），然后当检测到冲突时，当您从其他线程接收到响应时，您就可以更正UI。我喜欢动画/蒸发效果，让用户知道他们的操作已被覆盖，可能会使用状态栏（或类似的不引人注目的通知）消息来解释还原的GUI

---

如果您可以在操作开始时添加一些消息，您可以提供一些额外的反馈（同样是以一种不引人注目的方式），表明可能与另一个用户发生冲突。

在这种情况下，我认为警告消息告诉用户正在发生什么是唯一适当的行动。你可以通过设置B移动到其他地方（或消失）的动画来使你的GUI变得更加生动，但你所要做的只是让用户更加困惑——“WTF我不想把它移动到那里！”

---

编辑：我应该补充一点，我喜欢动画制作的想法，更重要的是我认为它本身不够。

我认为更大的问题是，为什么允许这样做？如果一个以上的用户可以做一些涉及大量时间的事情（在人的感知范围内），那么实时准确地描述多个用户之间的交互将使事情变得非常复杂

处理这种情况的更好方法是将对象处理为只读（因此存在w/o并发问题），直到用户声明独占使用其中一个或多个对象为止。此时，排他性锁要么成功（此时用户可以进行任何必要的更改），要么失败（在这种情况下，用户将获得反馈，例如在状态栏中“对象a、B、D、g已保留供其他用户独占使用”）