The first example "fixes" the bug with checking first, but without any lock on the resource. If key's existence is a key problem in that design, who guarantees that "some_key" is still there after the long computation? He might equally be returning a nonexistent key's value.
I think the problem is he's trying to use Redis as a transactional store while his design is not a good fit for it. He should either use a RDBMS for this stuff or change his design to match Redis' capabilities.
What I've tried to show in the safe_ips example is just one thing. That the safe_ips list does not have to be deleted to be modified. The fact that redis semantics allows us to atomically do that is awesome. If process B were to overwrite the write process A had done or the other wa around, due to some timing issues, is irrelevant in the context of this example. If that is a concern, then a multi-exec or a setnx with a time-value is the way to go.
The first example "fixes" the bug with checking first, but without any lock on the resource. If key's existence is a key problem in that design, who guarantees that "some_key" is still there after the long computation? He might equally be returning a nonexistent key's value.
I think the problem is he's trying to use Redis as a transactional store while his design is not a good fit for it. He should either use a RDBMS for this stuff or change his design to match Redis' capabilities.