Assignment 6 - Antme

Exam grade (out of 90)

Grade

Method is not fully deadlock-free, "synchronized (left) {
synchronized (right) {" alone can still cause deadlock

nice solution, minor issue: the delete method would need synchronization as well

the switch solution is funny :)

Good documentation + nice GUI

nice test, thread safe

works, good tests + discussion of other threats

Very good output and description. In the code, note that making the chopstick acquiring synchronized for each philosopher is not enough to avoid deadlocks, it just means that no two threads can execute this method for the same philosopher synchronous (but for different philosophers they can!).

Good documentation + nice GUI

nice documentation, thread safe

Very good documentation

nice solution, minor issue: seems not thread safe (what happens if two clients join at exactly the same time?)

good discussion of security issues

Extensive solution including GUI + nice theoretical analysis

Extensive documentation + GUI

Extensive documentation + GUI. Minor issue, why does it show in the chat messages the address of the receiving client, not of the sender? Regarding synchronizing the broadcast method, I don't think that is needed, since in the broadcast operation no data structures are modified (?)

Synchronization on single acquisitions is not enough, the access two both chopsticks together has to be made atomic in order to avoid deadlocks

Elegant solution with handedness

Concise solution, just the explanation how deadlocks are prevented is a bit vague. The key question is "how can the chopsticks be obtained without leading to deadlocks?"

nice discussion, minor thing: client registration seems not thread-safe (what if two clients join at exactly the same time?)

Nice solution, but the explanation is a little short. Also, no discussion of other threats than decryption (what about man-in-the-middle, traffic analysis, ...?

Synchronizing the acquireBoth() is not enough, as that just means that no two threads can execute the method for the same philosophers. But they still can for different philosophers!

Minor comment: The meaning of the terms "encode" and "decode" is the other way around

Works good, but note that your solution wastes some free resources (=chopsticks), e.g. if philosopher 1, 2 and 3 decide to eat (in this order), 3 cannot eat as the same time as 1, because the queue requires him to wait for 2 to eat first

Works nice, a solution to the buffering problem might be to buffer messages from the ListenFromServer class in the Client class, and only display them as long as the user has not pressed another key since the last "Enter" (has not started to type a new message again)

thread safety unclear. What might happen if two clients join exactly at the same time?

It seems the solution works only if both clients and servers run on the same machine. To extend it to several machines, keys would need to be sent over the network?