This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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." 

So, following the idea of the first note in defect #1076, sem_wait() and 
sem_timedwait() are now moved from cancellation entrypoints 'shall' to 'may'.  
The BZ#23006 was created to remove the cancellation checks done even for the fast 
paths where the call will not block.  My understanding is sem_{timed}wait should 
still be cancellation entrypoint for the *blocked* case, more specifically in the
code when futex calls might block indefinitely.  

It should also be noted that the 'Thread Cancellation Overview' rationale has a 
list of blocking entrypoints that are not listed in 'shall' and 'may' and 
sem_{timed}wait are not listed. I think to make sem_{timed}wait to *not* act
as cancellation entrypoint regardless we will need to open a Austin Group
Defect to update this rationale to include the semaphore functions.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]