设计模式:管理有限数量的资源 [英] Design Pattern: managing a limited number of a resource

问题描述

我正在为一个系统设计一个功能，我强烈认为必须有一个模式，在深入研究代码之前我应该​​知道.

I am in the process of designing a feature for a system where I strongly feel that there must be a pattern for this out there, that I should know about before diving into the code.

场景是这样的:

• 我有一个资源池，但数量有限.
• 我有不同数量的消费者使用这些资源；每个消费者只需要一种资源，并且在给定时间它可能不会与任何其他消费者使用相同的资源.
• 消费者被分成固定数量的组，系统需要保证每个组至少有一个资源.
• 每个组中的消费者数量随时间变化；它们会根据需要进行分配和解除分配.

我目前的做法是在启动时将资源放入两个堆栈:一个紧急堆栈"和一个公共堆栈".紧急堆栈将包含与组相同数量的资源(因此，每个组一个).其余可用资源进入公共堆栈.

My current approach is to put the resources into two stacks at startup: one "emergency stack" and one "common stack". The emergency stack will contain the same number of resources as there are groups (so, one for each group). The rest of the available resources go into the common stack.

当一个新的消费者即将被创建时，系统会请求一个资源.如果公共堆栈中有可用资源，则会从中弹出一个并返回给调用者.如果公共堆栈为空，则可能会从紧急堆栈中弹出资源，但前提是同一组中没有消费者已经拥有紧急资源.

When a new consumer is about to be created, the system will request a resource. If there are resources available in the common stack, one will be popped from it and returned to the caller. If the common stack is empty, a resource may be popped from the emergency stack instead, but only if there are no consumers within the same group that already has an emergency resource.

每当一个组内的消费者可以被释放时，相关的资源将被返回，并被推送到资源堆栈之一.负责释放消费者的代码将确保始终首先返回任何紧急资源，以便在将返回的资源推送到公共堆栈之前填充紧急堆栈.

Whenever a consumer within a group can be deallocated, the associated resource will be returned, and pushed onto one of the resource stacks. The code responsible for deallocating consumers will make sure to always return any emergency resources first, so that the emergency stack is filled, before returned resources are being pushed onto the common stack.

我觉得这种问题应该存在一种经过测试并证明有效的设计模式，所以我呼吁社区:你知道这样的模式吗?如果是这样，我恳请您赐教.

I feel that this is the sort of problem for which there ought to exist a design pattern that has been tested and proven to work well, so I call out to the community: do you know of such a pattern? If so, I kindly ask you to enlighten me.

更新

该解决方案现已实施，使用该问题的各种答案中的点点滴滴.我发表了一篇博文 关于它.

The solution is now implemented, using bits and pieces from various answers to this question. I published a blog post about it.

推荐答案

我可能只有一个资源堆栈、一个以计数组为键的数组/映射，以及一个没有资源的组计数.

I'd probably have a single resource stack, an array/map keyed by group of counts, and a count of groups that have no resources.

分配...

if group-counts [group] == 0
  pop resource from stack
  increment group-counts [group]
  decrement reserved-count

elseif reserved-count < stack.size
  pop resource from stack
  increment group-counts [group]

else
  fail

关键点是堆栈永远不会小于仍然有权要求立即资源的组的数量.

The key point is that the stack is never allowed to get smaller than the number of groups that still have the right to demand an immediate resource.

这种方法的一个优点是，如果需要，您可以使其更加灵活.假设一个群组有特殊需求，那么它可能在任何时候都需要两个资源.

One advantage to this approach is that you can make it a little more flexible if needed. Suppose one group has a special requirement, so it may need two resources at any point.

if group-counts [group] < group-reserved [group]
  pop resource from stack
  increment group-counts [group]
  decrement reserved-count

elseif reserved-count < stack.size
  pop resource from stack
  increment group-counts [group]

else
  fail

在这种情况下，reserved-count 从所有 group-reserved[] 值的总和开始.

The reserved-count in this case starts as the sum of all group-reserved[] values.

这个案例的发布逻辑是...

The release logic for this case is...

push resource to stack
decrement group-counts [group]
if group-counts [group] < group-reserved [group]
  increment reserved-count

对于简单的情况，使用if group-counts [group] == 0".

For the simple case, use "if group-counts [group] == 0".

这篇关于设计模式:管理有限数量的资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！