DS 2015 Grades
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAH
1
2
Student IDAssignment 1: Dining PhilosophersAssignment 2: Hamming CodesAssignment 3: TCP-ChatAssignment 4: RMI-ChatAssignment 5: RSA
Assignment 6 - Antme
1.11.21.31.42.12.22.33.13.23.33.44.14.24.34.45.15.25.35.4SUM
Exam grade (out of 90)
Course grade
3
GradeComment
Grade
CommentGradeComment
Grade
CommentGradeCommentGrade438381024484844443859890w/ assignments
4
1014024
Method is not fully deadlock-free, "synchronized (left) {
synchronized (right) {" alone can still cause deadlock
30
5
1142824see 10140 (above)3030
nice solution, minor issue: the delete method would need synchronization as well
30438081014484622003827725.6666666726.31666667
6
1120030
Solution with monitor is nice
30
the switch solution is funny :)
31
Good documentation + nice GUI
31
nice test, thread safe
30
works, good tests + discussion of other threats
313.5282.581024484823243828829.3333333329.76666667
7
1157830see 11200 (above)3031see above31see 1120030see above3143838102448454444383933131
8
1129527
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!).
31Nice GUI31
Good documentation + nice GUI
31
nice documentation, thread safe
31
Very good documentation
438281024384844243859431.3333333331
9
945327see 11295 (above)3131see above31see 1129531see above237082142.584844441.55.5274.524.8333333326.225
10
1113130Concise solution3031Nice GUI29
nice solution, minor issue: seems not thread safe (what happens if two clients join at exactly the same time?)
30
good discussion of security issues
293382.584244846444438588.529.530
11
1112030see 11131 (above)3031see above29see 1113130see above2903825124484344443827324.3333333326.21666667
12
1124631
Extensive solution including GUI + nice theoretical analysis
31
Extensive documentation + GUI
31
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 (?)
.438281024383.501.5440082752525.9
13
527924
Synchronization on single acquisitions is not enough, the access two both chopsticks together has to be made atomic in order to avoid deadlocks
--.11.500220.5340000220020206.6666666677
14
1041630
Elegant solution with handedness
30-.0380050.52.548280.50.50005.5249.516.517
15
1033130see 10416 (above)30-.
16
1159029
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?"
3031Nice GUI29
nice discussion, minor thing: client registration seems not thread-safe (what if two clients join at exactly the same time?)
29
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, ...?
1.5380520.543.582.5602.50435.526120.3333333322.7
17
1103224
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!
30
Minor comment: The meaning of the terms "encode" and "decode" is the other way around
-30see 11428303352.569244836432.5036.5276.525.526.175
18
1117528
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
--.300000000000000000000000
19
1108928see 11175 (above)3031see 1159029see 1159029see 3 above302382.589244948443.503828829.3333333329.55
20
1048324see email3031
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)
30
thread safety unclear. What might happen if two clients join exactly at the same time?
28
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?
1.534056.50.53483842.5113826822.6666666724.15
21
87740341500428300100110331111
22
74620000000000000000000000
23
103890000000000000000000000
24
1005011223805101.543.582.58330038173.524.524.5
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Summer exam + assignments
Fall exam
Winter Exam
 
 
Main menu