9 ms·
This reads like a system design interview, and a good one. The author clearly understands the pattern and the technologies they’re working with. I would perhap
by blowski 4y ago
This reads like a system design interview, and a good one. The author clearly understands the pattern and the technologies they’re working with.
I would perhaps attempt to gather more non functional requirements. How many items on the queue? How quickly are they added? How many threads are consuming from the queue? What’s the size of the message?
Also, how much would all this cost to run, in terms of memory? Is there a way of persisting the in-memory structure in case the server goes down?
- geocar 4y ago> This reads like a system design interview, and a good one. > The author clearly understands the pattern and the technologies they’re working with. We must have read a different article. The one I read put a big lock around the outside of their interface and called that "concurrent". This is not what is normally meant by the term. This was after a dozen or so pages that described an insertion sort poorly, and followed by some speculation about why their software still didn't work right.
- pipo234 4y agoAgree: soothingly well versed tone of voice, but leads to "it works"-level solution at best. Enumerates a bunch of data structures, but skips heap. Puts huge mutex over the interface, then even breaks open the abstraction to expose the lock using Hold()! So much for RAII.
- prettyStandard 4y agoI'm still reading and I am thinking wouldn't this be a "thread safe priority queue"?