Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Samuel Thibault]

Hello,

Agustina Arzille, on Wed 20 Apr 2016 00:35:20 -0300, wrote:
> Anyway, as promised, here's the lib: https://github.com/avarzille/hlpt

Thanks!

> Like I said before, I understand if people are uneasy with a whole new lib,

Well, that can be fine, but I'm sure there will be regressions, not only
conformance-wise, but also ABI-compatibility-wise, and they will be
difficult to spot if we replace the whole lib in one go, so I prefer to
go bit by bit.

> In my opinion, the low-level lock stuff should be added to glibc to
> replace most (all?) the spin locks.

Sure, all of the lock stuff would be extremely welcome!

> so feel free to pick what you feel is useful.

Well, "pick" is a dangerous word here: I'm pretty sure it's not merely
a matter of doing cp from hltp/ to libpthread/ :) There are at least
ABI concerns to be checked for instance (since the hltp structures are
smaller, one needs make sure programs built against hltp are not made to
run against the old libpthread, which would overflow the structure),
etc.

Unfortunately I personally have not much time to spend on the Hurd (I
have litteraly hundreds of more prioritized things to do...), so I don't
think I can take the time to sort out these details, I can only ask you
if you can have a look at that "picking" (though I should manage to be
available for reviewing it).

I'd say the priority order would be:

- pthread_spin_lock and mach's spinlock
- mach's mutex_lock (and thus libc_lock)
- pthread_mutex_lock & pthread_cond

Those are used extensively in translators, and profiling shows that they
are one of the major sources of overhead. That would probably boost
performance quite a bit.

- pthread_rwlock

Also used quite a bit in translators.

- semaphores (and notably sem_open, which would fix postgresql and quite
a few other packages which really need intra-process synchronization).

Samuel