1 files changed, 41 insertions, 0 deletions
diff --git a/demo2/ReadMe.txt b/demo2/ReadMe.txt
new file mode 100644
index 0000000..871eba6
--- /dev/null
+++ b/demo2/ReadMe.txt
@@ -0,0 +1,41 @@
+This demonstrates use of message queues via two applications named after
+Mrs. Premise and Mrs. Conclusion of the Monty Python sketch. 
+http://www.youtube.com/watch?v=crIJvcWkVcs
+
+Like those two characters, these programs chat back and forth and the result 
+is a lot of nonsense. In this case, what the programs are saying isn't the
+interesting part. What's interesting is how they're doing it.
+
+Mrs. Premise and Mrs. Conclusion (the programs, not the sketch characters)
+communicate with Sys V message queues.
+
+Mrs. Premise starts things off by creating the queue and sending a random 
+string (the current time) to it. She then sits in a loop receiving whatever 
+message is on the queue. If it is the same message she wrote, she sends it
+back to the queue. If it is a new message, it must be from Mrs. Conclusion.
+
+Meanwhile, Mrs. Conclusion is doing exactly the same thing, except that she
+assumes Mrs. Premise will write the first message.
+
+When either of these programs receives a new message, they send back an
+md5 hash of that message. This serves two purposes. First, it ensures that
+subsequent messages are very different so that if a message somehow gets
+corrupted (say by being partially overwritten by the next message), it will
+not escape notice. Second, it ensures that corruption can be detected if
+it happens, because Mrs. Premise and Mrs. Conclusion can calculate what the
+other's response to their message should be.
+
+Since message queues manage all of the concurrency issues transparently,
+Mrs. Premise and Mrs. Conclusion won't ever find their messages corrupted
+no matter how many messages they exchange. You can experiment with this by 
+setting ITERATIONS in params.txt to a very large value.
+
+These programs are not meant as a demonstration on how to make best use of a 
+message queue. In fact, they're very badly behaved because they poll the
+queue as fast as possible -- they'll send your CPU usage right up to 100%.
+Remember, they're trying as hard as they can to step one another so as to 
+expose any concurrency problems that might be present. 
+
+Real code would want to sleep (or do something useful) in between calling
+send() and receive(). 
+