Hi Dustin, Ben and all > Trond's already done that per-thread work and pushed it, so it's > ready in that branch. He's currently working on adding more locks to > a single hash table (a la java's ConcurrentHashMap).
Cool! I just started looking into how to hack this thing and found a limitation already heh (it's on the line of Ben's feedback). So, we update the state of the item structure (like, refcount and unlinking the item if expired) within do_item_get(). This reaaally doesn't work if multiple threads tries to fetch the same item. I can somewhat see ways to get this strategy working but it's going to be a HUGE surgery so I'm going to avoid it. There is something really cool that we can do with the external engine work though. This is going to be long and it probably won't make much sense to those that haven't been following the engine work but bare with me... it's only an idea at this stage ;) So, when we initialize a engine (e.g. the default slabber engine), the engine could create multiple instances of itself where each instance won't have to worry about locking internally at all. The engine will have the same amount of locks as the number of engine instances globally. When a GET command is issued to the engine, the engine would hash the key and make sure that the result is an integer within the number of engine instances. The engine would obtain the lock corresponding to that number (from the lock array) and lock that engine instance while it's does what it needs to do. This should hopefully reduce contention... hopefully. I think we can do something similar with the current codebase, as in not multiple instances but use an array of locks but I'm not sure how that would work out... I'll look into it and report it to you guys again :) Cheers, Toru On Fri, Mar 6, 2009 at 2:04 PM, Dustin <[email protected]> wrote: > > > On Mar 5, 7:11 pm, Toru Maesaka <[email protected]> wrote: > > >> As for the global stats_lock, I think its safe to assume that most of >> the operations are write related so read-write locking is definitely >> not the answer here. I think Facebook was dead-on with their solution >> on scaling this area up (use scoreboarding per thread basis and >> aggregate the results when needed). > > Trond's already done that per-thread work and pushed it, so it's > ready in that branch. He's currently working on adding more locks to > a single hash table (a la java's ConcurrentHashMap). > > The read/write stuff sounds pretty interesting, though. > >> To begin with I'm going to only experiment with using rw-locking for >> cache_lock. I'll test the performance with libmemcached's memslap and >> let you all know how it turned out... hopefully in not so distant >> future. > > Great. Trond still doing some work to reduce contention, that might > be an alternative approach. I think he was pretty far along with that > work, though. The results would be useful for general mutex strategy > advice.
