[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: Mon, 25 Apr 2016 12:31:17 -0300

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

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, 
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 
is because the horrible id->descriptor translation that is going on in 
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.

reply via email to

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