Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Samuel Thibault]

Hello,

Agustina Arzille, on Mon 25 Apr 2016 12:31:17 -0300, wrote:
> >>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.

Yes.

> 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/?

Since it depends on mach features only, it should be in mach.

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

Well, I wouldn't say so. Our current implementation does yield to other
threads, which is not what is usually done by spin lock implementations:
usually they really spin on the value, without making system calls, so
as to acquire as fast as possible. Such kinds of locks are of course
delicate to use: you have to control where threads are running,
otherwise you could be spinning for a whole scheduling quantum.

It happens that the current use of spin locks from translators assumes
that the spin locks are somehow yielding: they really don't do control
where threads are running.  These were converted as such from the
cthreads library, which does yield.  Probably we should just turn them
into using mutexes, which should become very lightweight with gsync.
But let's do step by step, so for now we have to keep pthread_spin_lock
somehow yield.  But yielding blindly like currently is done is not
the best way to achieve things, especially when we have the gsync
facility which allows to exactly get an optimized behavior with not much
overhead. Since we'll want to turn __spin_lock_solid (which is really
supposed to be somehow yielding) into using gsync anyway, that'll make
our current pthread_spin_lock implementation block with gsync, and get
better performance.

We can turn translators into using mutexes and then fix
pthread_spin_lock into really spinning, but independently.

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

Yes, __mutex_lock_solid gets overrided by the libpthread version.

> If so, it should only be necessary to rewrite the latter.

That'd only fix performance of multithreaded applications.
Non-multithreaded application will still be using the non-thread
__mutex_lock_solid which calls __spin_lock_solid which yields. But
again, I believe we want to fix that one into using gsync, anyway.

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

You mean the lock protecting __pthread_threads?  That's only used on
thread creation and pthread_self calls, which are really not that often,
actually, so that's not really the problem.

> Still worth to rewrite, because the algorithm in hlpt is very fast :)

We could integrate that optimization, yes. That's just not the most
pressing thing to fix for performances :)

Samuel