the item lock can only protect the hash list, but what about the LRU list?
As far as i know, if trying to delete a node from a doubly-linked-list, it
is necessary to lock at least 3 node: node, node-pre, node-next. I will
try to check if it may crash the LRU list in gdb next week .
And I
Seems like you're right.. I'd re-arranged where the LRU lock (cache_lock)
is called then forgot to update that one bit. Most of the do_item_unlink
code is safe there, until it gets into the LRU bits. It's unlikely anyone
actually saw a crash from this as it's a narrow race though.
That's easy to
:10 AM
To: memcached@googlegroups.com
Subject: Re: slab re-balance seems not thread-safty
Seems like you're right.. I'd re-arranged where the LRU lock (cache_lock) is
called then forgot to update that one bit. Most of the do_item_unlink code is
safe there, until it gets into the LRU bits. It's
Hi all,
I have thought carefully about the the thread-safe memcached recently,
and found that if the re-balance is running, it may not thread-safety. The
code do_item_get-do_item_unlink_nolock may corrupt the hash table.
Whenever it trying to modify the hash table, it should get cache_lock,
the item lock is already held for that key when do_item_get is called,
which is why the nolock code is called there.
slab rebalance has that second short-circuiting of fetches to ensure very
hot items don't permanently jam a page move.
On Wed, 2 Jul 2014, Zhiwei Chan wrote:
Hi all, I have
