Transcript os-lec6.ppt

Lecture 6
Mechanism/Policy
Deadlock/Scheduling
Mechanism and Policy
• Following page numbers refer to
Tanenbaum, our textbook.
Mechanism and Policy
• Page 44: minimal amount of mechanism
parameterized by policy. Split between
policy and mechanism is an important
concept: it occurs again and again in
operating systems.
Mechanism and Policy
• Page 93: separate scheduling mechanism
from scheduling policy. Scheduling
algorithm is parameterized in some way, but
parameters can be filled in by user
processes.
Mechanism and Policy
• Page 357: Memory Management
– Kernel contains mechanism
– Policy is decided by memory manager
– Allows to change memory management without
modifying lowest layers of the operating
system
Mechanism and Policy
Other instances
• Collaboration frameworks:
– mechanism: in framework
– policy: expressed by subclassing
• Traversals and visitors
– mechanism: in traversal
• from Directory to SimpleFile
– policy: in visitor
• DiskUsageAll, Find
Mechanism and Policy
Other instances
• Component-based software development:
– mechanism: in components
– policy: in connectors/adapters
• Abstract Pricing Mechanism
– Policies
• Regular Pricing
• Negotiated Pricing
• Sale Pricing
Related Pattern: Plug-Points and
Policy Plug-Ins
• Intent
– The aim is to allow modular and extensible
variety in an object’s behavior
• Considerations
– avoid proliferation of subclasses:
LongEmailReport, ShortEmailReport,
LongWebPageReport, etc.
Related Pattern: Plug-Points and
Policy Plug-Ins
• Solution
– Move variation points into separate objects and
have only one class of principal object. Use
Role Decoupling Pattern.
• Benefits
– additional plug-ins can be added without
altering the principal
– The plug-ins can be changed on-the fly
Also called: Strategy Pattern
Report
Generator writer
Report
formatter
writeOut()
Subclasses:
LongReporter
ShortReporter
etc.
writeOut() {
formatter.header(writer.getTitle());
while (x=writer.getNextPara())
formatter.paragraph(x);
}
Report
Formatter
Subclasses:
WebFormatter
EmailFormatter
etc.
Role Decoupling
• Intent
– The intent is to decouple by minimizing the
number of operations a client explicitly requires
• Considerations
– Most objects provide a variety of messages that
can be divided into separate interfaces; each
interface is used by a different class of client.
Allows substantial generalization.
Role Decoupling
• Strategy
– Declare every parameter and variable to be an
interface that specifies only the operations used
by that variable, and no more.
Library
Loan
*
Member
acceptLoan
endLoan
notifyHold
chargeFine
payFine
sendMail
*
Library
Loan
*
*
implements
Interface (Role)
LibraryUser
Interface (Role)
BookHolder
chargeFine
payFine
sendMail
acceptLoan
endLoan
notifyHold
Member
DisplayShelf