Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Agustina Arzille]

Hello, Samuel

On 04/24/2016 02:13 PM, Samuel Thibault wrote:
> > 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.

That's perfectly understandable.

> > 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!

OK. This, I think, needs to be in glibc, since that's where it is for other
platforms. I haven't patched anything in glibc yet, but I think the files:
https://github.com/avarzille/hlpt/blob/master/pthread/lowlevellock.c and
https://github.com/avarzille/hlpt/blob/master/pthread/lowlevellock.h

should be in the hurd/ directory? or maybe in mach/? For the first series
of patches, I'll put them in libpthread. Then we can add them in glibc.


> > so feel free to pick what you feel is useful.
>
> 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

Mmm. pthread_spin_lock* should be left as they are, since it matches users'
expectations best of what a spin lock is. For mach's spinlocks I agree, though,
since that interface should only be used internally.

Regarding mach's mutex_lock, and therefore libc_lock, am I correct in assuming
that they end up calling pthread functions once the lib gets linked in? If so, 
it
should only be necessary to rewrite the latter.

As for the last ones: I'll write up a patch for libpthread once I have time :)

> - pthread_rwlock

I'm half guessing here, but I think the reason this function gets called so 
often
is because the horrible id->descriptor translation that is going on in 
libpthread.
Still worth to rewrite, because the algorithm in hlpt is very fast :)

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

This one should be easy too.