I think that part of the point of the Santa Claus problem is to keep everything carefully synchronized. The Erlang and Erlang-inspired solutions are all inherently asynchronous, which means that other threads may be able to observe inconsistencies in state. This problem is compounded if you allow Santa's meeting to take up a random amount of time, something that I think most of these solutions ignore.
So I think refs are needed to guarantee this kind of consistency. Here's an example of how to do that: http://paste.lisp.org/display/79744 All the workers, as well as Santa, have a state that is contained in a ref. Transactions are used to guarantee consistency. This really showcases the STM system, and how composable these transactions are. Furthermore, you could easily hook each of these refs up to a GUI that shows you exactly what each worker and Santa are doing at any given instant in time. Everything would always be consistent. For example, the three elves would all switch from "waiting for santa" to "meeting with santa" simultaneously, and at the same time, Santa would show that he is now meeting with the three elves. I just don't think you get this kind of consistency from an asynchronous solution. When writing this code, I found the watcher system a bit clunky to use, and a bit too heavyweight for what I needed. Sometimes, within a dosync block, you want to trigger some sort of side effect once the current transaction is committed. To make this easy, I would very much like to see an addtional macro for the transaction system called after-commit, so that inside a transaction, you can easily do things like: (after-commit (println "Done committing")) This macro would add a function to a queue of functions to be invoked upon committing. If a retry occurs, the queue is thrown out (because the functions will be added again as part of the retry). The important point is that when one dosync block is called within another, it becomes part of the bigger transaction, so after-commit would happen after the bigger transaction completes. I believe this would have very nice composability properties, and allow for simple kinds of I/O and other side-effect functions to be invoked as soon as something commits for sure. Another minor gripe: when reorganizing the program for readability, I found it a hassle to have to explicitly type all the forward declarations. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
