

Software dev. final exam answers: Computer Architecture and Operating Systems - cperciva
http://www.daemonology.net/blog/2012-10-31-software-development-final-answers-part-2.html

======
gjm11
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_.)

~~~
throwaway54-762
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.)

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

~~~
throwaway54-762
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.

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

