Re: Re: pthread cancel cleanup and pthread_mutex_lock

[Patrick Oppenlander <patrick.oppenlander@gmail.com>]

On Wed, May 30, 2018 at 10:50 AM, Rich Felker <dalias@libc.org> wrote:
> This test is invalid. pthread_mutex_lock is not async-cancel-safe and
> cannot legally be called while cancel type is async.

I suspected as much.

> FYI something like 50% of the "Open POSIX Test Suite" tests are
> invalid; in the majority of cases they're testing some property after
> undefined behavior has been invoked like here.

Thanks. Do you know of any better tests?

>> I've run this test with musl, glibc and on some different platforms
>> with varying results:
>>
>> x86_64 linux 4.16.11, glibc: test runs to completion
>> x86_64 linux 4.16.11, musl: deadlock (cleanup handler doesn't run)
>> arm linux 4.16.5, musl: test runs to completion
>
> The test is invalid in other ways too, involving races. It attempts to
> use sched_yield to ensure that the test thread enters
> pthread_mutex_lock a second time, but there's no reason to expect that
> to do anything, especially if there are sufficiently many cores (as
> many or more than running threads). I suspect the different behaviors
> come down to just different scheduling properties due to performance
> differences, or something like that. Naively, I would expect the test
> to "work" despite being invalid.

The reason it doesn't "work" (besides being stupid) is because the
cleanup handler isn't invoked while the thread is blocked in the
pthread_mutex_lock call. Should it be in the async cancellation case?

>> What's the expected behaviour here?
>
> Nothing meaningful.

Thanks.

Patrick