db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{WelchWood97,
  title =        "{H}igher {L}evels of {P}rocess {S}ynchronisation",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Welch, Peter H. and Wood,  David C.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Bakkers,  Andr\`{e} W. P.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "104--129",
  booktitle=     "{P}roceedings of {W}o{TUG}-20: {P}arallel {P}rogramming and {J}ava",
  isbn=          "90 5199 336 6",
  year=          "1997",
  month=         "mar",
  abstract=      "Four new synchronisation primitives (SEMAPHOREs, RESOURCEs,
     EVENTs and BUCKETs) were introduced in the KRoC 0.8beta
     release of occam for SPARC (SunOS/Solaris) and Alpha (OSF/1)
     UNIX workstations. This paper reports on the rationale,
     application and implementation of two of these (SEMAPHOREs
     and EVENTs). Details on the other two may be found on the
     web. The new primitives are designed to support higher-level
     mechanisms of SHARING between parallel processes and give us
     greater powers of expression. They will also let greater
     levels of concurrency be safely exploited from future
     parallel architectures, such as those providing (virtual)
     shared-memory. They demonstrate that occam is neutral in any
     debate between the merits of message-passing versus
     shared-memory parallelism, enabling applications to take
     advantage of whichever paradigm (or mixture of paradigms) is
     the most appropriate. The new primitives could be (but are
     not) implemented in terms of traditional channels, but only
     at the expense of increased complexity and computational
     overhead. The primitives are immediately useful even for
     uni-processors -- for example, the cost of a fair ALT can be
     reduced from O(n) to O(1). In fact, all the operations
     associated with new primitives have constant space and time
     complexities; and the constants are very low. The KRoC
     release provides an Abstract Data Type interface to the
     primitives. However, direct use of such mechanisms still
     allows the user to misuse them. They must be used in the
     ways prescribed below else else their semantics become
     unpredictable. No tool is provided to check correct usage at
     this level. The intention is to bind those primitives found
     to be useful into higher level versions of occam. Some of
     the primitives (e.g. SEMAPHOREs) may never themselves be
     made visible in the language, but may be used to implement
     bindings of higher-level paradigms (such as SHARED channels
     and BLACKBOARDs). The compiler will perform the relevant
     usage checking on all new language bindings, closing the
     security loopholes opened by raw use of the primitives. The
     paper closes by relating this work with the notions of
     virtual transputers, microcoded schedulers, object
     orientation and Java threads."
}