Source code, lru_lock vs former cache_lock

[Slawomir Pryczek]

Hi, I was reading about LRU lock a bit and have a question regarding item_cachedump

unsigned int id = slabs_clsid;
id |= COLD_LRU;
pthread_mutex_lock(&lru_locks[id]);

1. Why in this code we're binary adding COLD_LRU, while for example in lru_crawler's code we're just using slab class IDs. This way other threads are able to access locked resources, is that correct?

2. 

pthread_mutex_lock(&lru_locks[slab_class_id]);

uint32_t hv = hash(ITEM_key(it), it->nkey);
void *hold_lock = NULL;
if ((hold_lock = item_trylock(hv)) == NULL) {
     continue;
}
if (refcount_incr(it) == 2) {

// LOCKED

Is it still correct way to lock an item so it can be safely read?

3. for the item_cachedump I found this comment

/* This is walking the line of violating lock order, but I think it's safe.
 * If the LRU lock is held, an item in the LRU cannot be wiped and freed.
 * The data could possibly be overwritten, but this is only accessing the
 * headers.
 * It may not be the best idea to leave it like this, but for now it's safe.
 */

Why it may violate lock order when we have only single lock acquired in this function? IS there some doc about correct (updated) lock order, the one in sources seems outdated...

Thanks,

Slawomir.

[dormando]

Hey,

That old "item_cachedump" command is deprecated. The locking is fine; it's
actually only looking at the COLD_LRU instead of walking all of them like
the lru_crawler.

I'd rather remove the command entirely than do any further work on it; it
has a hard limit on how many keys it can dump, it locks up the whole
worker thread while it fills the buffer, etc. The lru_crawler is superior
in all ways.

> --
>
> ---
> 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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/e19afc89-ccc1-4410-b6cf-3b005529df4an%40googlegroups.com.
>
>