The report is meant to convey very clearly to your reader how your solution works. If your explanation of the synchronization forced me to bring out a piece of paper and draw things out to understand what is going on then the report has not done its job. The most important things when documenting code (or any engineering design) is clarity and simplicity.
Think about it this way, in the old days mathematicians wrote theorems like this.
To find the length of the side that is the longest side of three sides in a triangle: take the other two sides and then for each of those sides compute the number that is that side multiplied by itself. Then those two results are to be added together to find a third number. That number shall be used to deduce the length of the side in question. This shall be done by computing the number that when multiplied by itself gives the number in question.
That's no good.
Here's how to express that more simply: A^2 = B^2 + C^2.
None of the reports were as bad as this but try to see the parallels. If there is a better simpler way to explain something then by all means use it. Trying to explain synchronization can certainly be made easier with a simple sketch/timing diagram/simple pseudo code of the main loop.
Few of the assignments correctly displayed cells with respect to the specification of the orientations given out. If you don't follow specifications that it makes it very hard for the marker to determine if your code actually works.
More importantly (in the real world) following specs make all the difference between a working project and one that doesn't work when said project is interfaced with other components of the real world.
Ugghhhhh. Bad bad bad. Sure in the old days of windows etc...people were forced to write multi-page switch statements for event handlers. This assignment was not a good excuse for such a sin. Several implementations had pages of if statements to determine which edge cells to copy.
You really should try to avoid the 'copy this page of code and change a few values' approach to programming. If the only thing that changes in your code is some values than make your code data driven. I.e read those values in from a precomputed structure/array etc....
As an example, if you're writing a server that responds to 100 different commands e.g "GET" "PUT" "ADD" etc... then a 100 element switch statement may be the way you decide to go...
But a much cleaner way would be to have an array of 100 function pointers, one for each command handler. Then you can use a hash table to find the correct command etc... You may argue this is less efficient (well in the real world if you had 100 commands you would use an integer id, nuf said).
Think of some of the reasons why this idea is important. What if your code needs a slight change, how are you going to change 500 'if' statements to use '>=' instead of '>'.
See the solution for one possible way to make the code more data driven in the part that updates neighbouring edges.
Most of the other comments were more minor and explained on the individual assignments. Also, see the reference implementation to see how your code differs. If you spot anything that one implementation does better then use that idea.
Learn from this project to improve on your next one. Hint: apply this idea recursively for guaranteed excellent results at some undefined point in the future ;-).