Come on, add another layer of indirection! When given a problem to solve, hand back another problem.
In this case:
Q: "I want the SIMPLEST possible way to synchronize two threads. What is it?"
A: The SIMPLEST possible way to synchronize two threads is a global maximal element (not necessarily unique) of a poset induced by a partial ordering on possible methods for synchronizing two threads. If the induced poset is totally ordered, and assuming that at least one possibly way of synchronizing two threads exists, then there exists a SIMPLEST possible way to synchronize two threads. If you hand me a method for comparing two synchronization methods for SIMPLICITY, then an algorithm retrieving such a best possible solution is trivial, but at this point you must define define what you mean by SIMPLEST before we can move any further.
Mr. Double PhD was trying to be clever.
"Here, run this unsigned code for me in your head." That has all kinds of possibilities . . .
[See John Barnes' book _Candle_ if you want some scary prognostication. Warning, it's kind of graphic and disturbing in spots]
Of course it fails if you're working in user mode. Or you have non-maskable interrupts that you need to sync with.
In this case the poor PhD x 2 had been working for years on consumer PCs, which were at the time nearly all single CPU. I'd been mucking about with multiprocessing a fair amount, and the IRQL thing never even occurred to me during the interview. Just as well.
Copy-paste.
Btw = if you're worried about conflicts - it's Ok there's a second file called "writeStatus.txt" which you have to claim by replacing the String NULL with your processId - thereby claiming write access to data.txt and causing any other processes to Thread.Sleep until it's free.
Unrelated, who's hiring...
>Copy-paste.
You may joke, but it's the most universally supported, and therefore the most likely to be available.
I was ushered in. The Guy with Two PhDs (he showed me his business card first, and there were indeed two PhDs on it) asked me:
"What is the simplest way to synchronize two threads?"
I rattled off some synchronization primitives. Semaphore. Critical section. I was ready to do an implementation if he wanted.
"No, the simplest."
I dug around. Interlocked operations? A mutex? A spinlock? I mentioned Dekker's algorithm (it sucks, but it's simple). I dredged up a few more.
"No, I want the SIMPLEST possible way to synchronize two threads. What is it?"
I'd run out. He gave a disgusted snort. The next question wasn't much better: "What's the BEST way to share data between programs?"
"Not sure what you mean by best. How many programs? Is it over the network? Hmm, shared memory and a maybe a signal of some kind?"
"No, the best way!"
This interview did not go well. At the end, Dr. DoublePhd scolded me for dropping out of college and told me to go back to school to finish my degree.
That evening I wrote the hiring manager that Dr. DoublePhd appeared to want the answer "raise interrupt priority" for the thread synchronization question -- which doesn't work on a multiprocessor -- and that I had no idea what the heck he was asking for on the other questions.
I didn't add that even the awful questions I was being asked could have been productive interview fodder in the hands of a good interviewer, but that in the hands of a terrible person they were destroying that company's ability to hire.
Turns out that I didn't need to add that last bit. A few months later the hiring manager emailed me, saying that they had fired Dr. DoublePhd and would I consider interviewing again? I politely declined.
I never found out the BEST way to share data between programs. In fact, I'm still looking. I think we all are.