5 ms·

Type -1 candidates quit on the spot when they discover that memcached has, in the years since they last worked with it, been bastardized to do things other they

Type -1 candidates quit on the spot when they discover that memcached has, in the years since they last worked with it, been bastardized to do things other they GET and SET! The beauty of memcached in the 2000s was that it felt extremely opinionated about features — that is to say, it didn’t have any. That bool incr argument in the source code feels like a hint from the authors. The arithmetic feature was meant to do two things and two things only, represented by I/D = +/- = true/false. Add (pardon the pun) any more operations and here be dragons. In particular once you add MULT, some clown is going to ask for DIV, and so are you now going to convert ints to floats or force integer division on everyone? Let’s place bets on how long until we get a “bug” report that 12,999,999 DIV 10 should be 13 not 12. Maybe I’m being unfair. The integer increment thing in memcached seems useful. The useful part of it is the fact that it increments atomically, not that it does the heavy lifting of adding one for you :P If N people increment it you get a number that is N bigger. “Add 1” is also a pretty easy thing to get consistent if you have two people contending for a lock. If it were a strongly typed language it would have a type like Counter (not Number) and it makes no sense to multiply a counter. The hint is also there in the INCR and DECR commands. They are probably not called ADD and SUBTRACT for a reason. Feature rejected! Now let’s go code up MULT anyway :)

xxs 5y ago
I'd say MUL(T) is absolutely useless in any practical manner. I'd take some form of CAS if I want atomic operations. MUL has to deal with overflow a lot more than inc/dec. Not knowing the value prior MUL, taking any branches is another issue, CAS would solve in that case as well. Inc/dec are useful for a counter implementation (although I see no reason to have a designated dec) - even though counters should not be implemented in such a manner, e.g. each writer should have its own counter, and reader should sum them up when the value is needed. No contention, scalable. In that regard I'd consider the interview question "weak", lacking a deeper understanding - not just show us you can code.
- gorgoiler 5y ago
  Oh it’s a great question. Code this solution without having to worry about why. If only the job was actually like that. The why is 10x the how, IRL, once you get beyond IC0.5.
jodrellblank 5y ago
> "They are probably not called ADD and SUBTRACT for a reason." You'll be pleased to know they aren't called that in the protocol, but they actually are that. They take a delta value so you can do "incr 5" to add 5 and internally the function is named "add_delta" not "incr"[1]. (Beware because it's not quite subtraction, going negative is forbidden. (3 + 5 - 5 == 3) but (3 - 5 + 5 == 5)). [1] which means the answer in the followup blog post (and my answer) to overload the same function to handle multiplication as well makes the function name even less accurate.

xxs 5y ago

I'd say MUL(T) is absolutely useless in any practical manner. I'd take some form of CAS if I want atomic operations. MUL has to deal with overflow a lot more than inc/dec. Not knowing the value prior MUL, taking any branches is another issue, CAS would solve in that case as well. Inc/dec are useful for a counter implementation (although I see no reason to have a designated dec) - even though counters should not be implemented in such a manner, e.g. each writer should have its own counter, and reader should sum them up when the value is needed. No contention, scalable. In that regard I'd consider the interview question "weak", lacking a deeper understanding - not just show us you can code.

gorgoiler 5y ago
Oh it’s a great question. Code this solution without having to worry about why. If only the job was actually like that. The why is 10x the how, IRL, once you get beyond IC0.5.

jodrellblank 5y ago

> "They are probably not called ADD and SUBTRACT for a reason." You'll be pleased to know they aren't called that in the protocol, but they actually are that. They take a delta value so you can do "incr 5" to add 5 and internally the function is named "add_delta" not "incr"[1]. (Beware because it's not quite subtraction, going negative is forbidden. (3 + 5 - 5 == 3) but (3 - 5 + 5 == 5)). [1] which means the answer in the followup blog post (and my answer) to overload the same function to handle multiplication as well makes the function name even less accurate.