说出该技术的名称（可能称为“搭载”）

发布于 2024-08-24 02:44:27 字数 595 浏览 3 评论 0原文

以下方法/技术的名称是什么（我将尽力描述，可能需要“记忆”背景才能理解为什么该技术非常有用）

：一些可能很长的异步计算，并且您意识到相同的计算已经开始，但尚未完成，并且您“搭载”了第一个计算。然后，当第一次计算结束时，它发出的不是一个而是两个回调。

目标是不要不必要地启动第二次计算，因为您知道已经有一个相同的计算正在运行。

请注意，尽管并非完全不同，但我并不是在寻找缓存的特殊情况，“记忆化”是：记忆化是当您开始计算并找到已经完成的相同计算的缓存（记忆化）结果时您可以重复使用。

在这里，我正在寻找与记忆化有点相似的技术名称（因为它可以出于某些与记忆化是有用技术相同的原因而有用），只不过它重用了第一个计算即使在您发出第二个计算时第一个计算尚未完成。

我一直将这种技术称为“搭载”，但我不知道这是否正确。

实际上，我不止一次地使用过它作为某种“类固醇记忆”，而且它非常方便。

我只是不知道这种（高级？）技术的名称是什么。

编辑

该死，我想对 epatel 的答案发表评论，但它消失了。 epatel 的回答给了我一个想法，这种技术可以称为“惰性记忆”：）

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

幸福丶如此 2024-08-31 02:44:27

这只是期货的记忆。

正常的“热切”记忆是这样工作的：

f_memo(x):
  critical_section:
    if (exists answers(f,x))
      return answers(f,x)
    else
      a = f(x)
      answers(f,x) = a
      return a

现在，如果 f(x) 返回 futures 而不是实际结果，则上面的代码按原样工作。你会得到捎带效应，即像这样：

第一个线程调用 f(3)
没有存储 f(3) 的答案，因此在关键部分有对 f(3) 的调用。 f(3) 被实现为返回一个 future，因此“答案”立即准备就绪；上面代码中的“a”被设置为未来的 F 并且未来的 F 存储在答案表中
未来的 F 作为调用 f(3) 的“结果”返回，这可能仍在进行中< /strong>
另一个线程调用 f(3)
从表中找到未来的 F，并立即返回
现在两个线程都掌握了计算结果；当他们尝试读取它时，他们会阻塞，直到计算准备好为止——在帖子中提到这种通信机制是通过回调实现的，大概是在 future 不太常见的情况下

This is just memoization of futures.

Normal "eager" memoization works like this:

f_memo(x):
  critical_section:
    if (exists answers(f,x))
      return answers(f,x)
    else
      a = f(x)
      answers(f,x) = a
      return a

Now if f(x) returns futures instead of actual results, the above code works as is. You get the piggyback effect, i.e. like this:

First thread calls f(3)
There is no stored answer for f(3), so in the critical section there's a call to f(3). f(3) is implemented as returning a future, so the 'answer' is ready immediately; 'a' in the code above is set to the future F and the future F is stored in the answers table
The future F is returned as the "result" of the call f(3), which is potentially still ongoing
Another thread calls f(3)
The future F is found from the table, and returned immediately
Now both threads have handle to the result of the computation; when they try to read it, they block until the computation is ready---in the post this communication mechanism was mentioned as being implemented by a callback, presumeably in a context where futures are less common