libthr shared locks

Daniel Eischen deischen at
Wed Feb 17 17:38:00 UTC 2016

On Wed, 17 Feb 2016, Konstantin Belousov wrote:

> On Tue, Feb 16, 2016 at 12:27:12PM -0500, Daniel Eischen wrote:
>> On Tue, 16 Feb 2016, Konstantin Belousov wrote:
>>> On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote:
>>>> My only comment on kern_umtx.c is, why are the permission checks compiled out?
>>> Assume that we changed the ABI of libthr and shared locks do not require
>>> an offpage.
>> How are you coming with that?  I thought maybe you were going to think
>> about making the synch types structs, but not actually changing the
>> implementation (yet).
> Are you asking what is the state of the work for changing the libthr
> ABI by replacing object pointers with inline structures, am I reading
> the question right ? (Sorry, english is not my native language)

I am sorry, my question was not phrased very well.  Sometimes I
am amazed that non-native English speakers can write better English
than native English speakers :-)  But, yes, that was my question.

> I do plan to introduce inlined objects (most likely in the form of
> libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my
> plans are to get the existing patch for pshared into the tree for 11.0.
> After that I wanted to implement robust mutexes, still in the context of
> the libthr. Then libthr2.

As soon as this is done, will we build FreeBSD base OS against
the new API?  So only ports would be affected.

I was hoping to see partially inlined objects (with the first word
being a pointer to the allocated object, just like now) in for 11.0.
So by 12.0 we could make the switch over to fully inlined.

If we introduce either partially or fully inlined objects for 11.1
(with your libthr2), how does that affect our ability to move to
fully inlined by default (base & ports) for 12.0?  We would not
have had a full release cycle for the ABI change.

> Finishing the current patch for 11.0 is the immediate goal, while I did
> not forget neither abandoned the inline alternative and do plan to work
> on it.



More information about the freebsd-threads mailing list