This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Add pthread_cond_timedwaitonclock_np
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Mike Crowe <mac at mcrowe dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 27 Jul 2015 15:26:23 -0400
- Subject: Re: [RFC] Add pthread_cond_timedwaitonclock_np
- Authentication-results: sourceware.org; auth=none
- References: <1436277389-22478-1-git-send-email-mac at mcrowe dot com> <alpine dot DEB dot 2 dot 10 dot 1507221351430 dot 21570 at digraph dot polyomino dot org dot uk> <20150727190048 dot GA5841 at mcrowe dot com>
On 07/27/2015 03:00 PM, Mike Crowe wrote:
>> New APIs also need documentation in the glibc manual.
> I'm having some trouble with the safety section. pthread_cond_timedwait
> isn't documented in the glibc manual since it is a POSIX function.
> The pthread_cond_timedwait man page tells me that pthread_cond_timedwait is
> MT-Safe but it's presumably neither AC-Safe nor AS-Safe. I'm not sure what to put in
> the asunsafe and acunsafe reasons. Cut and paste gave me:
Yes, the pthread_* functions are by definition MT-safe.
> is this correct?
Note: Use of "aculock" for acunsafe. Here it matters that the lock is lost
not that we deadlock.
With suggested source level comments like this:
@c If exactly the same function with arguments is called from a signal
@c handler that interrupts between the mutex unlock and sleep then it
@c will unlock the mutex twice resulting in undefined behaviour. Keep
@c in mind that the unlock and sleep are only atomic with respect to other
@c threads (really a happens-after relationship for pthread_cond_broadcast
@c and pthread_cond_signal).
@c In the AC case we would cancel the thread and the mutex would remain
@c locked and we can't recover from that.
> (I also plan to submit changes to the pthread_cond_timedwait man page.)
> Thanks for the review.
This does not constitute a full review, and I think a lot more people need
to review this before we have consensus over a new API like this.