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{Welch13b,
  title =        "{M}utually {A}ssured {D}estruction (or the {J}oy of {S}ync)",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Welch, Peter H. and Pedersen,  Jan Bækgaard and Barnes,  Frederick R. M.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Welch, Peter H. and Barnes,  Frederick R. M. and Broenink,  Jan F. and Chalmers,  Kevin and Pedersen,  Jan Bækgaard and Sampson,  Adam T.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "319--320",
  booktitle=     "{C}ommunicating {P}rocess {A}rchitectures 2013",
  isbn=          "978-0-9565409-7-3",
  year=          "2013",
  month=         "nov",
  abstract=      "In contrast to the Client-Server pattern, Mutually Assured
     Destruction
(MAD) allows the safe opening of communication
     by either of two
processes with the other.  Should both
     processes commit to opening
conversation together, both are
     immediately aware of this and can take
appropriate action -
     there is no deadlock, even though the
communications are
     synchronous.  A common need for this pattern is in
real-time
     control systems (e.g. robotics), artificial
     intelligence,
e-commerce, model checking and elsewhere.  A
     typical scenario is when
two processes are given a problem
     to solve; we are satisfied with a
solution to either one of
     them; whichever process solves its problem
first kills the
     other and makes a report; the one that is killed
     also
reports that fact.  In this case, the opening
     communication between
the two processes is the only
     communication (a kill signal).  If both
solve their problem
     around the same time and try to kill each other,
MAD is the
     desired outcome (along with making their reports).  A
simple
     and safe solution (verified with FDR) for this pattern
     with
occam synchronous communications is presented.  This is
     compared with
solutions via asynchronous communications. 
     Although these avoid the
potential deadlock that a naive
     strategy with synchronous
communications would present, they
     leave a mess that has to be tidied
up and this tidying adds
     complexity and run-time cost.  The Joy of
Sync arises from
     the extra semantic information provided by
synchronous
     communications - that if a message has been sent,
     the
receiving process has taken it.  With this knowledge
     comes power and
with that power comes the ability to
     implement higher level
synchronisation patterns (such as MAD
     and Non-blocking Syncs) in ways
that are simple, verifyably
     safe and impose very low overheads."
}