On Tuesday 24 June 2008, Jérôme Vuarand wrote: > That is quite an interesting thread, though I'd like to come back to a > point that has been discarded too quickly in my opinion. > > 2008年6月19日 Javier Guerra <javier@guerrag.com>: > > An obvious improvement might be to use finer locks, maybe one per > > mutable object; but a pthread mutex lock weights between 40 and 64 > > bytes each. way too much. readers/writer locks are even bigger. this days i've been reading about lock implementations, and found this (http://people.redhat.com/drepper/futex.pdf), reimplemented in C i get 4 byte locks, and first tests show that could also work at 1byte. they're also noticeably faster than pthread locks, especially in the non-contented case (up to 60-70% faster). the non-contented case is interesting, because since they're totally userspace in this case (only call the kernel if the lock is contented), and using a lock per object means a lot less contentions and higher opportunity for concurrency. > In some applications (mine at the very least), a 40 to 64 bytes > overhead per mutable object would be very acceptable. Did someone > already try to patch Lua source code to have per-object locks ? unfortunately it's an all or nothing proposition: if used, _all_ objects would have to have a lock. even small throw-away tables that wouldn't ever be shared. it's important to keep the impact as low as possible > Also if implemented like the default Lua global lock mechanism (ie. > with macros), it could be a good basis to experiment with custom locks > (1bit per object), hashed locks, or a combination of both. and furwoks! ('Fast Userspace RW lOcKS') -- Javier
Attachment:
signature.asc
Description: This is a digitally signed message part.