by Xin Li

First, I want to make clear that what is a mechanism or a policy. For a
system, mechanism is something underling it and support the running of
it. A mechanism can't be modified after being created. The policy is a
method to use the mechanisms. It can be changed in some circumstance. Here
I want to divide policies into 2 kinds further. Some policies are provided
to adapt the applications. I call them the explict policies. The others
are the goals of the designers which are implied in the mechanisms and not
intend to change. I call them implicit. For example, we all have feet and
hands. That's a mechanism and it implies that we use feet to walk and use
hands to write. So this is implicit policies. They are not intend to
change, but there does exist someone writing with their feet, doesn't
there? However, the ways we walk or write are explicit policies.

In fact, there is no mechanism without any implicit policies. We can see
it from the following 2 systems.

In the lottery scheduling system, the tickets that clients hold and the
operations on tickets, such as transfering, inflation, currency and
compensation are all mechanisms. All the other methods to use those
mechanisms are policies, whether implicit or explicit. The lottery
scheduling (Each allocation is determined by hoding a lottery, the
resource is granted to the client with the winning ticket) which is said
by the designer as a mechanism, is actually an implicit policy. This is
just the goal of the designers.

Similarly, in the resource container system, the containers, attributes,
bindings, and the other operations on resource containers are all
mechanisms, and the exact ways of resource management are all explicit
policies. Although the designers stress that resource containers are just
a mechanism, we still find implicit policies in it. For example, they
allow an application to associate scheduling information with an activity
rather than with a thread or process. The server is surposed to create a
new container for each connection and assign one free thread to service
it. If a connection consumes a lot of resources, this comsumption is
charged to the resource container to make the priority of the associated
thread decay. These are all implicit policies implied by the resource
container mechanism and are also the goals of the designers.