A graphical-component library can provide protected void paintComponent(Graphics g) as a subclass customization hook, as in javax.swing.JComponent. A subclass overrides it to draw its own contents while the library retains responsibility for the surrounding painting protocol. A protected method in Java is accessible to code in the declaring package and to subclasses in other packages subject to the receiver restriction; it is not simply a public method and not exclusively subclass-visible.
The benefit is controlled extensibility without exposing an ordinary client operation. If the method were private, external subclasses could not override and reuse it as the intended hook. If it were public, arbitrary clients could call it outside the normal painting lifecycle and the library would have a wider public contract to maintain. Protected hooks still require documented invariants because subclass code participates in the implementation.
Use LRU replacement, or a modest recency-based approximation, for eligible buffer-cache entries. Unlike individual memory accesses, buffer cache lookups already pass through operating system code. Updating an LRU replacement list on each lookup is therefore practical: remove the accessed entry from its old position and put it at the most-recent end; choose the oldest unpinned entry as victim. A hash lookup plus a doubly linked recency list makes this bookkeeping constant time.
Good temporal locality favors retaining recently used blocks. FIFO page replacement's arrival-only criterion can evict a block used moments ago. CLOCK page replacement can save bookkeeping, but the difficulty of observing arbitrary memory references that motivates it is absent for software-mediated block accesses. Dirty victims require write-back, so a policy can favor an old clean buffer or arrange background cleaning without discarding recent hot data. A long one-pass scan can pollute pure LRU replacement; scan-resistant variants are useful refinements rather than a reason to ignore recency altogether.
A buffer cache keeps copies of device blocks in main memory, indexed by device identity and block number. It reduces expensive repeated device reads and can combine several modifications into one write. It also gives software a controlled place to hold data while requests are in progress.
On a read, the operating system looks up the block. A valid cached copy gives a hit and supplies the data; a miss reserves an eligible buffer, writes its old contents first if dirty, issues the device read, and marks the new contents valid when the transfer completes. A write modifies the buffer and marks it dirty. Under a write-back policy, a later flush or eviction sends it to the device; under write-through, completion also waits for the required device write. Dirty state differs from “currently in use”: a pinned or locked buffer cannot simply be reused while a request depends on it.
A buffer cache needs synchronization for concurrent readers, writers and in-flight transfers, and should avoid inconsistent independent copies of the same block. Explicit flushes and ordering are needed when durable storage is required; caching alone does not guarantee that an acknowledged in-memory update survives a crash. Replacement chooses among eligible buffers, preserving dirty data before reuse.
Represent a binary search tree by:
sml
datatype ('k, 'v) dict = Empty
    | Branch of ('k, 'v) dict * 'k * 'v * ('k, 'v) dict;
Assume the provided lookup d key returns NONE or SOME value, and update d (key, value) returns the updated binary search tree. Traverse the first dictionary, retaining only a key with the same value in the second:
sml
fun intersection equal d1 d2 =
    let
        fun visit Empty result = result
          | visit (Branch (left, key, value, right)) result =
              let
                  val r1 = visit left result
                  val r2 =
                      case lookup d2 key of
                          NONE => r1
                        | SOME other =>
                            if equal (value, other)
                            then update r1 (key, value)
                            else r1
              in
                  visit right r2
              end
    in
        visit d1 Empty
    end;
For equality-type values, call intersection (op =) d1 d2. An explicit value comparison parameter also handles values for which Standard ML does not define built-in equality. This distinguishes absent keys from defined values without reserving a sentinel value.
Every inserted entry belongs to both input dictionaries with the same value, so the result agrees with each. Conversely, each common equal-valued entry is visited in d1, found in d2, and inserted. Any dictionary agreeing with both can contain only those entries. Thus the result is exactly the largest common dictionary, not merely an intersection of key sets. If d1 has entries, lookup height is , and maximum result-tree height during insertion is , the time complexity is for constant-cost comparisons. Logarithmic heights require a balancing assumption; an ordinary unbalanced binary search tree can have linear height.
Generate every permutation of the tail, then insert its missing head at every possible position. The helper preserves order among the elements already present:
sml
fun insertEverywhere x [] = [[x]]
  | insertEverywhere x (y :: ys) =
      (x :: y :: ys) ::
      List.map (fn zs => y :: zs) (insertEverywhere x ys);

fun permutations [] = [[]]
  | permutations (x :: xs) =
      List.concat
        (List.map (insertEverywhere x) (permutations xs));
The first helper result inserts before ; the mapped recursive results put back at the front and insert farther along. For a list of length , it yields exactly positions. The empty list has one permutation, itself, so the base result is [[]], not [].
For correctness, use structural induction. Any permutation of x :: xs has a unique position containing . Removing that position leaves a permutation of xs, supplied by the induction hypothesis; reinserting at its unique position reconstructs the required output. With distinct input elements, neither the tail permutation nor the insertion position can be duplicated, so each output occurs once. Consequently a length- input yields exactly permutations, in an unrestricted order. The explicit output is large; this is not a polynomial-time enumeration with respect to alone.
True in the intended comparison with traditional Unix protection mechanisms. Windows XP provides object-specific access control lists, subject tokens containing identities and privileges, and a security reference monitor. Rights can distinguish operations on files, registry keys, processes and other protected objects. Traditional Unix file permissions distinguish read, write and execute for owner, group and everyone else; unrestricted root authority also makes privilege separation coarse. The richer Windows XP mechanisms can express finer least-privilege policies. Cambridge's access-control notes describe this architectural contrast.
This is an architectural capability comparison, not a claim that every Windows XP installation resists attacks better than every Unix installation. More complex authorization is not itself a proof of security; configuration and implementation matter, and Unix variants can add access control lists and other protection mechanisms. Without specifying that traditional model, the blanket comparison is underspecified.

There are unlisted articles, also show them or only show them.