POPL Open Part 2 ================ NB. o Part 1 (Essay) grade feedback is via the online feedback system. o For *both* parts, individual comments have been written on your hard-copy submissions. These may be viewd at the same time as the script-viewing sessoins for yuor Sping Closed papers. Class comments -------------- Task 2 ------ With only 500 words available it is crucial that your answer is well focus and does not contain irrelevant material. The question clearly states that the problem does not need to be described. Also space should not be used to defined semaphore or monitors, etc. Coverage is important, so using all the space to describe just two issues did not lead to a high mark. The question asks for a review, and hence the use and correct citation of sources (from the net and elsewhere) is key. I expected at least 10 and perhaps 20 citations. I got much fewer and they were often not relevant, or very general (to wiki or similar). Remember when referring to a url you must give the date that you last accessed it. Most students scored 'ok' on this, with marks around 8 or 9 (out of 15), a few did a lot better, a few did a lot worse. Good points to make linked the DPP with: deadlock, livelock, race conditions and fairness randomized solutions with probabilistic guarantees distribute, symmetric and asymmetric solutions semaphores, monitors and message-passing (synch. and asynch.) Different solutions used waiters/conductors/footmen hygienic and drinking philosophers a trusted fork dispenser dirty and clean forks two coloured or numbered forks In terms of languages, the focus should have been on using DPP to illustrate language features, not how to implement DPP in language X. Languages that have used DPP to at least illustrate include: Java, Ada, Concurrent Pascal, Concurrent Haskell, Haskell#, occam, Scala, CSP, SC++, ORC, C#, C++, Concurrent C, Eifel, python, Erlang, Ruby, SR, and Algol 68. One student added to my list with: Clojure, Common Lisp, E, Euphoria, F, Go, JoCaml and Logtalk (but did not give citations so I could not check up on these). Task 3 ------ One of the points I made during the last tutorial (where I went over the Java problem) was that layout of code (especially in Java with its extensive use of }s) was important (I gave a version without exception handlers, I/O or comments to show the basics of the solution). This advice was, in general, not followed. The layout of code was often very poor and almost unreadable. Many just did not seem to check what the code looked like on paper (rather than the screen); as a result line overruns added to the confusion. Comments are useful. But over commenting hinds the code. Comments such as fork++ // add one to value of fork eat() // call method eat to simulating eating are pointless. You must assume that the reader knows the language basics. If you have chosen sensible names for objects then additional comments are unnecessary. Only comment on the more complex and less obvious parts. I also mentioned in my presentation the difficulty in getting program output from a concurrent program to fully illustrate the program's behaviour. Output such as Phil X get cutlery Phil X eats Phil X thinks where X is a classy name does not really tell the story. It does not show who X is sat next to, or which forks they get, or the state of the plates. Another poor presentational aspects in many submissions was the lack of any introduction, or overview of the approach. Often the code needed to be read in detail to work out what was going on. Also to note is that some people ignored the question which asked for monitors. Using the predefined Java class for semaphores is not acceptable (lead to marks been lost, but still passing mark if used correctly). In terms of solution, about 1/4 went for the single monitor approach. This is 'ok', but not ideal. It really collapses all resources into one, and can lead to a polling solution with liveness issues (though not deadlock). Also think about the problem if there were 1000 philosophers - the single monitor (with lots of notifyAlls) would be inefficient and a bottle neck. A solution with a monitor per resource is preferred. Then the issue is ask for plate first or fork? A few correctly realised that asking for the plate first (as there was only 3) itself prevented deadlocks. No further protection was necessary. Many who went for forks first and noted that 2 plates were enough. But still had blocking code for the plates!! You should have had confidence to miss this out. The issue of 'notify' or 'notifyAll' is interesting. The single monitor solution needs while loops and notifyAll. But for the single resource per monitor it is clear that only one thread can be released and hence a simple 'if wait()' and notify is more efficient. Finally I noted that 4 people did the solution in Ada, and 6 in Pascal-FC. The rest in Java. A completely adequate program could be done in about 1.5 pages in Pascal-FC or Ada languages. Java takes more, and for some much more. Many of perhaps the more able students added lots of bells and whistles to their solutions. This made it difficult to get to the required aspects of the solution and tended to loose rather than gain marks. Notwithstanding all these observations most people scored highly on this problem.