[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: another try at multithreading
- From: Javier Guerra Giraldez <javier@...>
- Date: Tue, 24 Jun 2008 19:45:08 -0500
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 <firstname.lastname@example.org>:
> > 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
> 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')
Description: This is a digitally signed message part.