Re: [PATCH] nptl: Remove cancellation checks from sem_{timed}wait (BZ #23006)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 25/06/2019 09:17, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 24/06/2019 14:17, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> The Austin group has decided that sem_wait and sem_timedwait do not need to
>>>> be cancellation points.  This patch removes the cancellation checks in order
>>>> to improve performance.
>>>>
>>>> As for comment #2 in BZ#23006, the old implementation which explicit check
>>>> for cancellation is moved to a compat symbol.
>>>
>>> The code nptl/sem_waitcommon.c still acts on a cancellation request, I
>>> think.  The only change is that if we do not wait at all, we do not act
>>> on the cancellation.  I don't think this matches the POSIX semantics,
>>> where cancellation points are either there or not, and do not depend on
>>> function implementation details.
>>
>> My understanding is defect #1076 is to make it more clear when exactly the
>> 'may' cancellable entrypoints should act upon cancellation request, more
>> specifically that cancellation should be used as a mechanism for preventing 
>> indefinite blocking.
>>
>> Also, imho this specification does not clash from the 'Thread Cancellation 
>> Overview' [1], which states that:
>>
>> For functions in the "may occur" list, a cancellation check may be performed
>> on some calls but not others; i.e., whether or not a cancellation point occurs 
>> when one of these functions is being executed can depend on current
>> conditions."
> 
> My impression is that doesn't mean that the behavior is random (although
> the wording allows for that).  It's dependent on how things have been
> configured, and not on which threads wins a race during the call.

My understanding is pthread cancellation is a mechanism to abort unbounded block
from a thread. Being random is not meaningful here (where the sem_{timed}wait 
would block or not).

> 
> Any cancellation model which makes functions a cancellation points only
> if they block has this problem.  It also means that future optimizations
> (in glibc, the kernel, or the silicon) could effectively remove
> cancellation points.  I don't think this is desirable.

That's why I think to make sem_{timed}wait *not* a cancellation entrypoint
would need to open a Austin Group defect, it is explicit that the only
blocking routines that not act as a cancellation are pthread_mutex_lock,
pthread_barrier_wait, pthread_spin_lock.