I was pleasantly surprised by Colin's rationale for asking the first question. (That was the one about MESI cache coherence; Colin hoped that many people wouldn

I was pleasantly surprised by Colin's rationale for asking the first question. (That was the one about MESI cache coherence; Colin hoped that many people wouldn't know the answer offhand but would work out what it had to be. And, in fact, many people did just that.) Not so convinced by the fourth. That was the one about why pthread_cond_wait takes a locked mutex as a parameter, and here's what Colin says: "I think this was the most important question on this part of the exam: [...] if you don't understand race conditions, you will can end up writing code which is broken [...] And before anyone objects that this is only relevant to multi-threaded programming: Race conditions are also responsible for many security bugs where a program races against an attacker". If the most important thing on this part of the exam was to find out whether people understand race conditions because race conditions are important even when not writing multithreaded code, testing their familiarity with one particular bit of one particular threading API seems like an eccentric way to find that out. And it's not like the MESI cache coherence question: just knowing the name pthread_cond_wait doesn't give much hope of deducing what's going on from general principles. (Full disclosure: I got full marks on Q1 by exactly the method Colin was hoping for, and no marks on Q4 because I have never used pthreads and wasn't smart enough to deduce the answer from general principles. You may wish to apply an appropriate discount to my guarded approval of Q1 and disapproval of Q4. For the avoidance of doubt, giving me no marks for Q4 was exactly right, and I think Q4 would be fine as a sort of proxy for being familiar with multithreaded programming. I just don't think it's a good question given what Colin says it's aiming to get at.)