Re: RFC: Lightweight synchronization mechanism for gnumach v3

[Agustina Arzille]

Hello, Samuel,

On 04/17/2016 12:24 PM, Samuel Thibault wrote:
> Hello,
>
> Ok, but why not just fixing pthread_mutex_lock & such in our current
> libpthread, instead of having yet another implementation?  How are we
> supposed to handle those three implementations: Neal's, nptl, and yours?
>
> Ideally your reimplementation is perfect and we can throw away Neal's,
> but nobody can be perfect when writing a pthread library (been there,
> didn't do that ;) ), so I'm really not at ease with throwing away Neal's
> implementation which we have fixed over years.
>
> Samuel

The implementations for pthread objects (mutexes, condvars, etc) that
I have right now can be easily transplanted into the current lib without
much issue. 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.

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

- Instead of creating thread descriptors with malloc, I place them at the
  top of the stack.
- 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.

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 :)

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.