Re: futexes

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Jason Thorpe <thorpej%me.com@localhost> wrote:
> On Aug 16, 2020, at 5:58 AM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
> 
> 
> Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>>> From: Robert Swindells <rjs%fdy2.co.uk@localhost>
>>> 
>>> Is anyone working on the proposed solution to kern/55230 ?
>> 
>> thorpej was working on it and has a patch -- I thought it got
>> committed, but I guess not?  There might have been some hard-to-fix
>> bug remainining in it but I forget the details.
> 
> Would it help to have more people testing and/or looking at it ?

>The fix is non-trivial, and requires a fundamental change to how futexes
>work.

That seemed clear in the bug, I guessed it would mean switching to using
a futex_syncobj (or similar).

>That said, I've made the change, and it fixes the unit test, and to
>exercise it more thoroughly, I also started converting several pthread
>locking interfaces to use futex beneath, while also enhancing the test
>cases for those pthread interfaces to verify proper priority ordering.
>However, the changes started to grow without bound and then I ran into a
>time crunch.
>
>What I should do is wind my code back to the basic "just fix the futex
>internals" change, and publish there so that others can work on it.  The
>main sticking point is that Linux Java was getting stuck ... all of my
>unit tests were passing, however.  This is why I started working on
>native users -- to provide more coverage and possibly make it easier to
>debug that problem.

I'm mainly interested in Linux Java, it seemed fairly easy to find
test cases that got stuck.

Happy to do some work on simplifying the patch, or just identifying
good test cases, if it will help.