You hit the nail on the head. We explicitly did not care about how "well" the solution was written (some solutions were very surgical, others involved a lot of copy/pasta, some folks wrote very detailed comments, etc.), although we did point out and ask you to fix solutions that were incorrect. For example, some candidates implemented "mult" as "add" in a loop, with the row lock acquired and released in each iteration. This solution is vulnerable to a data race if another user concurrently updates the value.
It seems a simple way of building the "mult" solution as a composition of the existing primitive(s), here "add". But agreed, that I would not find the tradeof acceptable either.
Yes - so the safe thing to do is to put the lock outside the loop. Anyone experienced in multithreading will instinctively know this is the correct alternative for any codebase (and it performs better too).
