Internal Quotas

Why do quotas exist in software? Their role is to curtail overages consumed by a program. We could let the hardware decide how to handle these situations, but users probably wouldn't appreciate that much. How are quotas measured and how do we decide on an upper limit that regulates the consumption of one resource or another? The easy way to decide on a upper quota limit is to measure the physical hardware limits. Portions of the physical resource are made available to software that needs it. Allocating quota limits gets interesting when several competing software units are in contention for it. Abstract software objects that need memory, a thread that needs CPU time, or an entire program that needs both - these are all things that need resources and also need quotas.

Think about programs running on your operating system. The OS to decides who gets to use the CPU at any given time. If there is more than one CPU, the same logic applies - it is also up to the OS to decide which programs get to use each CPU. This is an example of a software quota. Once the program starts executing instructions, it only has so long before it must relinquish control of the CPU. This quota, the number of instructions executed by the program during it's CPU occupancy, is established by the OS. The best a program can do is manage it's own internal quotas.

What types of resources would a program want to restrain? If the underlying operating system manages physical hardware access, why bother? In dynamic programming languages, we don't need to explicitly allocate memory or tell the threading mechanism to switch contexts. There is more to quota management in software than just the physical hardware limitations.

Software is created with a problem domain in mind. In object-oriented software, different classes represent different concepts in the problem domain. Can we use these concepts as a basis to assign quota limits? For instance, if I've got two containers, one that stores user objects and one that stores document objects, I can limit these as I deem fit. I could give the user object container a quota that limits it to having no more than 100 objects at a given time. I could limit that document container to having only 10. I just made these limits up. The point is that you have the ability to do this based on the business requirements of your software, not necessary having to occupy all physical resources until the OS says your quota is exhausted.

The same idea applies to processor time within your program. If your application has several threads, you are in control of what domain concept gets to use the CPU, not leaving it up to the the OS that knows nothing about your problem domain. Understanding the domain concepts in your code and the ability to assign quotas to them gives you much more control and flexibility than you may have thought possible.