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

查看:104
本文介绍了设计模式:管理资源有限数量的的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在一个系统设计功能的过程中,我强烈地感到,必须有这个在那里的模式,我应该知道潜入code之前。

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.

每当一个组内的用户可以被解除分配,相关的资源将被返回,并且压入资源栈中的一个。在code负责释放消费者将确保总是先返回任何应急资源,使应急堆被填满,返回之前资源被压入堆栈共同

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

在这种情况下,保留的计数开始,因为所有的基团的保留[]值的总和。

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

对于简单的情况下,使用如果群计数[组] == 0。

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

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

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆