Software dev. final exam answers: Computer Architecture and Operating Systems | Hacker News Reader

Software dev. final exam answers: Computer Architecture and Operating Systems

daemonology.net

14 pointscperciva5 comments

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.)

Agreed on Q4 — if understanding race conditions is what Colin was driving at, Q4 was simply a bad question for it.

A better wording might be: "What surprising behavior could occur if `pthread_cond_wait` didn't take a locked mutex?"

(Full disclosure: I also scored a zero on Q4. However, I'm familiar with both pthreads and the necessary atomicity between releasing the lock and waiting on the condition, so this was a surprise. He was obviously fishing for a specific answer, but I couldn't figure out which from the question.)

I can't tell from your user name and your comment which person you are -- can you tell me what your answer was?

Sorry, I'm embarrassed now that I know what you were actually looking for.

I will say: my answer did mention the need to atomically release the lock and then wait on the condition, but it was buried in a bunch of other crap that was not what you were looking for.

If you really want, I'll send you an email — let me know.

I wonder if the scores for Q2 were skewed upwards due to a recent Stack Overflow question which illustrated the principle of sequential disk reads in a similar scenario.

(SO is down right now, so I can neither find it nor tell when/whether it was poster here on HN or over on /r/programming.)

Reply on news.ycombinator.com