problem: today i need 4 packets to make 'lock'/'unlock' using memcache i need to use less ROM/CPU/RAM/network at client side
solution: 1) make server side lock function with 2 packet (with atomic operations) 2) make a proxy if function = lock/unlock, proxy make these packets to server (i don't have atomic here, but i can implement with a big work on protocol, maybe a new memcached hehe) i will try the second one without atomic (today i'm using it, i have some problems, but client side workaround it with more packets... (retry) ) the first is better (i don't need a proxy, i have less packets, use less cpu, ram, rom, time) packets: LOCK add value (1 packet sent by client, 1 packet sent by server) if no error (end here) if value exist read value (1packet sent by client, 1 packet sent by server) if value=my value (my lock) if not (not my lock) UNLOCK read value (1packet sent by client, 1 packet sent by server) if value != my value (end here) delete value (1packet sent by client, 1 packet sent by server) (end here) 2011/2/5 Dustin <[email protected]>: > > On Feb 4, 12:20 pm, Roberto Spadim <[email protected]> wrote: >> it´s not the case, i will study redis maybe a protocol change can >> solve the problem >> lock is just for computer world >> it´s a mix of pic(gpio + logic) and computer >> it´s work very well, to problem is pic have low cpu memory and rom, in >> future i will change to ARM/x86 >> i will try other solution maybe a proxy between memcache and pic with >> lock unlock function > > While you haven't described your exact problem enough for anyone to > offer a reasonable solution, what you've described doesn't sound like > a problem that you can solve by swapping out a KV cache with a KV > store. > > I'd guess the easiest thing to do is to actually move the logic into > the server via a job queue. If you don't think this will *greatly* > simplify your program and make it considerably faster, more reliable, > easier to maintain and solve all of your problems, then please > describe your problems as well as you've described your proposed > solutions. -- Roberto Spadim Spadim Technology / SPAEmpresarial
