3 ms·

Redis being single-threaded has always been its single most important advantage in my opinion. It eliminates whole classes of possible bugs and makes the softwa

by jwr 8y ago

Redis being single-threaded has always been its single most important advantage in my opinion. It eliminates whole classes of possible bugs and makes the software much simpler.

jdsully 8y ago
I’ve managed to get a few fixes upstreamed that are more inline with Antirez’s vision. I hope to continue that in the future. The beauty of open source is choice, and getting to try new things.
bufferoverflow 8y ago
That's not a good enough reason not to write multithreaded software. You can apply your reasoning to almost any software, and it will fail all the same. Performance and latency matter. A lot.
- jwr 8y ago
  > That's not a good enough reason not to write multithreaded software Possibly not, but it's a very good reason not to use multithreaded software, when a simple single-threaded alternative is present. It's a very practical decision in my case: I'd rather rely on something that I know eliminates entire categories of bugs, if performance is acceptable (it is for me). Also, if it breaks, I can dive in, understand it and fix it. Simplicity should not be underrated.
harryh 8y ago
Multi-threading is not some crazy new fangled idea. A huge portion of the software you use every day is multi-threaded. It's not that hard to get right. I don't see why the redis maintainers don't have the skills to do it.
- toast0 8y ago
  Retrofitting multi-threading into an existing design, is actually a pretty big challenge. Especially if you're going with shared everything multi-threading as is common in C. I won't name and shame, but I've started using a well known "internet scale" project that recently added multithreading, and have run into three major locking errors already. These are smart people, they've written a great program, but they didn't make the right locking decisions. The approach antirez mentioned in a sibling thread of a multithreaded proxy process that communicates to multiple single threaded instances sounds much easier to implement without ending up with data in the wrong places. Although, even that doesn't necessarily need to be multithreaded either. A master process doing healtchecking and sending status to the worker processes, that are using a eventloop would probably work just as well.
- deleted 8y ago
  [deleted]
gjs278 8y ago
memcached is multi threaded and I've never had an issue with it.

by jwr 8y ago

Redis being single-threaded has always been its single most important advantage in my opinion. It eliminates whole classes of possible bugs and makes the software much simpler.

jdsully 8y ago

I’ve managed to get a few fixes upstreamed that are more inline with Antirez’s vision. I hope to continue that in the future. The beauty of open source is choice, and getting to try new things.

bufferoverflow 8y ago

That's not a good enough reason not to write multithreaded software. You can apply your reasoning to almost any software, and it will fail all the same. Performance and latency matter. A lot.

jwr 8y ago
> That's not a good enough reason not to write multithreaded software Possibly not, but it's a very good reason not to use multithreaded software, when a simple single-threaded alternative is present. It's a very practical decision in my case: I'd rather rely on something that I know eliminates entire categories of bugs, if performance is acceptable (it is for me). Also, if it breaks, I can dive in, understand it and fix it. Simplicity should not be underrated.

harryh 8y ago

Multi-threading is not some crazy new fangled idea. A huge portion of the software you use every day is multi-threaded. It's not that hard to get right. I don't see why the redis maintainers don't have the skills to do it.

toast0 8y ago
Retrofitting multi-threading into an existing design, is actually a pretty big challenge. Especially if you're going with shared everything multi-threading as is common in C. I won't name and shame, but I've started using a well known "internet scale" project that recently added multithreading, and have run into three major locking errors already. These are smart people, they've written a great program, but they didn't make the right locking decisions. The approach antirez mentioned in a sibling thread of a multithreaded proxy process that communicates to multiple single threaded instances sounds much easier to implement without ending up with data in the wrong places. Although, even that doesn't necessarily need to be multithreaded either. A master process doing healtchecking and sending status to the worker processes, that are using a eventloop would probably work just as well.
deleted 8y ago
[deleted]

gjs278 8y ago

memcached is multi threaded and I've never had an issue with it.