jeff571

3 ms·

1.
by jeff571 9y ago
People who bother to practice for coding interviews (using the same website) and successfully land an interview do similarly well on coding interviews... That's a lot of selection bias.
2.
by jeff571 9y ago
"Training existing Ruby developers to maintain safe C++ code would take too much time." Wow. Just wow.
3.
by jeff571 9y ago
Yeah exactly! Just look at DPDK for example.
4.
by jeff571 9y ago
It's in their codebase because they catastrophically over engineered it. Even the largest codebases on earth don't require FactoryFactoryFactory's.
5.
by jeff571 9y ago
I'm sorry but you can't possibly be serious. There is no sane motivation for a *FactoryFactoryFactory class. No problem on earth is complex enough to benefit from that much abstraction.
6.
by jeff571 9y ago
The article is an okay start, but it wasn't written by an expert. It lists some real pitfalls but doesn't provide commonly accepted solutions. Some examples... multiple lines: wrap in do { } while (0) - can use a multiline macro l
7.
by jeff571 9y ago
The lock could still be faster. atomic ops are more expensive than regular opcodes even when there is zero contention. On x86, a lock requires only a single atomic opcode and can be released with a normal write (because of TSO). Since it&#x
8.
by jeff571 9y ago
Keep in mind lockless algorithms are not necessarily more scalable than lock-based algorithms, usually have higher constant overheads, and are significantly easier to get wrong. However, this post is, in part, about how to implement locks.