[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Lightweight synchronization mechanism for gnumach v3

From: Agustina Arzille
Subject: Re: RFC: Lightweight synchronization mechanism for gnumach v3
Date: Sun, 17 Apr 2016 22:29:17 -0300

Hello, Samuel,

On 04/17/2016 12:24 PM, Samuel Thibault wrote:

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]