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 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, but the function do_item_get have not got the cache_lock.
> Please tell me if anything i neglected.
>
> /** wrapper around assoc_find which does the lazy expiration logic */
> item *do_item_get(const char *key, const size_t nkey, const uint32_t hv) {
> //mutex_lock(&cache_lock);
> item *it = assoc_find(key, nkey, hv);
> if (it != NULL) {
> refcount_incr(&it->refcount);
> /* Optimization for slab reassignment. prevents popular items from
> * jamming in busy wait. Can only do this here to satisfy lock order
> * of item_lock, cache_lock, slabs_lock. */
> if (slab_rebalance_signal &&
> ((void *)it >= slab_rebal.slab_start && (void *)it <
> slab_rebal.slab_end)) {
> do_item_unlink_nolock(it, hv);
> -------------------------------------------------------------------> no lock
> before unlink.
> do_item_remove(it);
> it = NULL;
> }
> }
>
> --
>
> ---
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
>
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
