Re: another try at multithreading

[Javier Guerra Giraldez <javier@...>]

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.