Paper Details

db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"
@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"
  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"
  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"
  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."
}

If you have any comments on this database, including inaccuracies, requests to remove or add information, or suggestions for improvement, the WoTUG web team are happy to hear of them. We will do our best to resolve problems to everyone's satisfaction.

Copyright for the papers presented in this database normally resides with the authors; please contact them directly for more information. Addresses are normally presented in the full paper.