Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Samuel Thibault]

Hello,

Agustina Arzille, on Sun 17 Apr 2016 22:29:17 -0300, wrote:
> The implementations for pthread objects (mutexes, condvars, etc) that
> I have right now can be easily transplanted into the current lib without
> much issue.

Ok, good :)

> I also have the implementation for what glibc calls
> 'low-level lock' i.e. a wrapper around something like futex. That can be
> integrated into glibc to replace spin locks where needed as well.

Ah, cool, indeed :)

Also, the spin_lock functions from glibc/mach's spin-lock.h could be
made to use it instead of calling __swtch_pri().

> The reason why I chose to rewrite libpthread is because there are many
> things that I disagree with the current one.

Ok, that's true that some things can probably be improved.  Take care
however that some seemingly odd things are actually needed for proper
POSIX behavior :)

> - Instead of creating thread descriptors with malloc, I place them at the
>   top of the stack.

This might be questionable too.  Is the goal just to save the
allocation?  I'm not sure it's worth making the code more complex just
for this (think about application-provided stack and such).

> - Instead of using a TLS slot for the current thread, I use a field in the 
> TCB.
> - Instead of looking up the signal state with 'mach_thread_self', I have it
>   cached inside the thread descriptor.

Right, these would improve the access.

> Those are some of the many differences I can think of right now. I don't mean
> to disparage Neal's work; I simply think that since we have a better tool for
> synchronization, it's time to revamp libpthread :)

Right, but rewriting from the start looks to me like wanting bugs :)

> In any case, I'll be uploading my work to some git repo within the next days. 
> If
> you guys consider it too much to use a new libpthread, then we can always
> cherrypick what it's best and incorporate it to what the Hurd currently has.

Richard Braun, on Mon 18 Apr 2016 10:27:35 +0200, wrote:
> I agree, we shouldn't cling on our current implementation, and I'm
> sure we can deal with the bugs in short time with our experience and
> Agustina's help.

I have to disagree. libpthread bugs are never easy to sort out.  We only
know about bugs when actual applications make use of a special case or
scenario.  Replacing the now-well-tested libpthread with another one
means suddenly getting a lot of bugs to be tracked...

Samuel