Status of multithreaded code

[Steve Grimm]

You've identified a piece of dead code, left over from a refactoring while I
was developing the thread support. I should have removed that -- will go do
it now. If that code was called, you're quite right that it would have a
nasty bug.

The multithreaded code is fully operational. We are running it on 200+
4-core memcached hosts where it processes tens of thousands of requests a
second all day long.

-Steve


On 5/25/07 6:01 PM, "Ben Hartshorne" <memcache at green.hartshorne.net> wrote:

> All,
> 
> I saw a --enable-threads option in the configure script, along with a
> thredas.c that contained multithreaded code.
> 
> What is the status of this code?
> 
> I was looking at the code for mt_item_get_nocheck to get an item
> regardless of its deleted status.
> 
>     392 /*
>     393  * Returns an item whether or not it's been marked as expired or
> deleted.
>     394  */
>     395 item *mt_item_get_nocheck(char *key, size_t nkey) {
>     396     item *it;
>     397
>     398     pthread_mutex_lock(&cache_lock);
>     399     it = assoc_find(key, nkey);
>     400     it->refcount++;
>     401     pthread_mutex_unlock(&cache_lock);
>     402     return it;
>     403 }
> 
> If assoc_find returns 0 (which it does if the item is a cache miss), it
> looks to me as though the function will segfault when it tries to
> derefernce it in line 400.
> 
> Thoughts?
> 
> The corresponding single-threaded function checks to make sure it is
> valid before derefencing it:
> 
>     402 /* returns an item whether or not it's delete-locked or expired. */
>     403 item *do_item_get_nocheck(const char *key, const size_t nkey) {
>     404     item *it = assoc_find(key, nkey);
>     405     if (it) {
>     406         it->refcount++;
>     407         DEBUG_REFCNT(it, '+');
>     408     }
>     409     return it;
>     410 }
> 
> -ben