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.
diff --git a/thread.c b/thread.c
index 8db7237..606fb88 100644
--- a/thread.c
+++ b/thread.c
@@ -526,12 +526,7 @@ int item_link(item *item) {
* needed.
*/
void item_remove(item *item) {
- uint32_t hv;
- hv = hash(ITEM_key(item), item->nkey);
-
- item_lock(hv);
do_item_remove(item);
- item_unlock(hv);
}
/*
