5 ms·
The hiring manager of a small software company gave me a quick brief before handing me off to his technical heavy. "He's hard to get along with, but he's really
by kabdib 10y ago
The hiring manager of a small software company gave me a quick brief before handing me off to his technical heavy. "He's hard to get along with, but he's really smart. Oh, and he has two PhDs. He'll tell you that."
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.
- satysin 10y agoIf someone asks you the "best" way to do something but does not give you context for the problem being solved then the question is stupid. There is no all-purpose "best" way to do anything when it comes to complex systems. You use the "best" way for the problem in hand that may be shared memory, pipes, writing to a file, RPC, etc.
- harveywi 10y agoExactly. When handed an under-specified problem (semantics), hand back a lambda compiled in the target language (syntax). "What do you mean? African or European?"
- kabdib 10y agoUpvote for "hand back a lambda". I was laughing. "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]
- havetocharge 10y agoWell put. If there was the best way, then it would be the only way.
- harveywi 10y ago> I never found out the BEST way to share data between programs 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.
- mping 10y agoJust run one after the other.
- johndubchak 10y agoOMG...too funny.
- phyushin 10y agoI think we've found Dr double Phd ;)
- zhte415 10y ago> I never found out the BEST way to share data between programs. In fact, I'm still looking. I think we all are. Copy-paste.
- Ntrails 10y agoSee, I was gonna go with Data.txt in a shared network drive. 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...
- willis77 10y agoBut who has access to writeStatus.txt? Classic rookie mistake. You needed a writeStatusWriteStatus.txt.
- btschaegg 10y agoSounds like playing Byzantine Generals on the file system :)
- zhte415 10y agoFlat files FTW, Just need to re-invent server-client architecture using freely available tools and you're at management level kudos,
- TuringTest 10y ago>> I never found out the BEST way to share data between programs. In fact, I'm still looking. I think we all are. >Copy-paste. You may joke, but it's the most universally supported, and therefore the most likely to be available.
- TheGrassyKnoll 10y agoFor Linux users its gotta be the pipe. Works great.
- 10y ago
- kazinator 10y ago"Raise interrupt priority" is not a way to synchronize threads, let alone the simplest. I know what I'm talking about; I worked on multithreading for Linux before the rewrite to NPTL and I invented the PTHREAD_MUTEX_ADAPTIVE_NP type that you still find in Glibc. On a project several years ago, I did use interrupt priority in conjunction with threads as a complete hack. The issue was this: the interrupt service routines for an IDE-based compact flash were running CPU intensive polling loops, taking away app CPU time. I created a priority scheme where certain interrupt priority levels overlapped with thread priority levels. That is, it was possible to suppress the interrupts for this IDE device while certain important threads were dispatched. As in, automatically: when the kernel dispatched a thread in that priority range, interrupts below that value would be blocked (not by disabling CPU interrupts, but the actual interrupt controller's detailed mask of interrupts, where we pick the specific ones that get masked). When the thread lost the CPU, they would be unblocked. This solution/workaround worked well enough to deal with the issue it was intended for.
- kabdib 10y agoYou can raise IRQL and get okay synchronization on simple systems. It was fine for early versions of Unix, and I've used it quite a bit on uniprocessor embedded systems. Just a few instructions, hard to get wrong. 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.
- llukas 10y agoMy guess would be that simplest way to sync two threads is exit them both. ;)
- btschaegg 10y ago...or not running them in the first place.