jeff571's comments

jeff571 | 8 years ago | on: We looked at how a thousand college students performed in technical interviews

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.

jeff571 | 8 years ago | on: How Rust Is Tilde’s Competitive Advantage [pdf]

"Training existing Ruby developers to maintain safe C++ code would take too much time."

Wow. Just wow.

jeff571 | 8 years ago | on: Choosing between programming in the kernel or in user space

Yeah exactly! Just look at DPDK for example.

jeff571 | 8 years ago | on: A FactoryFactoryFactory in Production

It's in their codebase because they catastrophically over engineered it. Even the largest codebases on earth don't require FactoryFactoryFactory's.

jeff571 | 8 years ago | on: A FactoryFactoryFactory in Production

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.

jeff571 | 8 years ago | on: How to properly use macros in C

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 like a function call, terminated with ; or ({foo; bar;}) - multiple lines evaluate to 'bar'...

Function calls: - in general anything with side effects could be harmful if evaluated more than once. - But possible to write MIN()/MAX() with single evaluation of 'a' and 'b'. #define MAX(a, b) \ ({typeof(a) _a = (a); typeof(b) _b = (b); _a > _b ? _a : _b;})

And other important things like stringify, variadics, etc...

jeff571 | 8 years ago | on: What every systems programmer should know about lockless concurrency [pdf]

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's uncontended it won't spin at all. Therefore, any alternative lock-free algorithm that uses more than a single atomic op is actually more expensive.

jeff571 | 8 years ago | on: What every systems programmer should know about lockless concurrency [pdf]

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.