Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Memcached work planned for contribution back to memcached/memcached
C++ C CMake Other
Latest commit c1935ff @trondn trondn Remove testing code
Change-Id: I09364a2c5fe763ba2bad4ee9c229f583fc5c948f
Reviewed-by: Dave Rigby <>
Tested-by: buildbot <>
Failed to load latest commit information.
auditd MB-16621: Ensure consumer thread terminates
cbsasl Convert pwfile.c to C++
daemon Close open sockets in the destructor
engines EWB_Engine: Add support for injecting NOT_MY_VBUCKET
etc MB-14423: Initial support for Greenstack
extensions Remove testing code
include MB-16186: Add NO_VALUE flg for DCP client to indicate server to strea…
man/man4 MB-16063: Add support for connection timeout
programs BIO_read/write may return 0 and we should look at retryability
protocol flatbuffers v.1.2.0 don't need --get-includes
support-files Add SMF manifest files
tests Create topkeys benchmark
testsuite Use CB_C,CXX_FLAGS_NO_OPTIMIZE for building unoptimized targets
time MB-16056: Remove/replace assert() with cb_assert; ban assert()
utilities MB-16685: Add mapping of message 0xb8 (get keys)
.gitignore Generate command timings
.mailmap Added a .mailmap
CMakeLists.txt MB-14423: Initial support for Greenstack
COPYING add a duplicate of the LICENSE file so GNU automake doesn't assume it…
LICENSE change from GPL to BSD. Add a readme with locking information Undefine ntoh functions on linux to avoid warnings
memcached_dtrace.d Tynset - A multi-bucket default_engine
trace.h MB-8723: Bring back support for DTrace probes


memcached is using a number of threads:

  • The dispatcher thread listens on all of the server sockets, and accepts a client connection which is then dispatched to the worker threads on a round robin model.

  • The TAP thread is responsible for serving all TAP communication.

  • The number of worker threads is specified with the threads parameter in the configuration. The worker threads are responsible for serving the clients requests, and the number of worker threads cannot be increased at runtime.

Some commands is implemented by dispatching separate threads to execute the user command. There is currently no checks trying to protect ourself from clients trying to allocate too many threads (but the commands themselves is not available to the average user. See RBAC.json)

  • Bucket creation/deletion
  • Reload of the SASL password database

Connection object

The Connection class represents a Socket (it is used by both clients and servers objects). We should refactor the code so that it represents client connections and have a separate object (and state machines) for a server object.

The Connection object is bound to a thread object, and never change (except for clients running TAP, which is moved over to the TAP thread after the initial packet...)

Locking scheme

A client is bound to its worker thread when the client is created (let's ignore the TAP threads, they're special and should hopefully die ;-)). When the clients event loop is triggered, it acquires the threads lock and runs the entire state machine. This means that the thread can safely access any resource available in the LIBEVENT thread object. Given that it already holds a lock to a LIBEVENT thread object it is NOT allowed to try to acquire ANY other thread locks. That would lead to a deadlock.

Given that all of the clients share the same set of worker threads, the clients cannot block while waiting for a resource to become available. The model in use is that we're expecting the engines to return EWOULDBLOCK and we're expecting the client to run the task in a different thread and call notify_io_complete when the resource is available. The reason it has to be a different thread is that notify_io_complete WILL try to lock the thread object where the connection is bound to (which would cause a deadlock if called while holding a thread lock).

Something went wrong with that request. Please try again.