it is very important lock. if items not yet send back (still in pipeline to return to client) you will get access violation. Other option to copy item to buffer but this is unacceptable solution due memory limitation.
On Wednesday, March 25, 2015 at 10:05:52 AM UTC-7, Charlie Curtsinger wrote: > > There appears to be an unnecessary lock acquisition in the item_remove > function (thread.c:528). This function calls do_item_remove (items.c:368) > which atomically decrements a refcount and frees the item if the refcount > goes to zero. I see no reason that this call should be guarded by a lock. > > Removing this lock improved the throughput of a simple SET/GET workload ( > https://github.com/antirez/mc-benchmark) by 9% when I run memcached with > a large number of threads. A patch is attached. > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
