Bug#884776: libc6: pthread_cond_broadcast() blocks indefinitely on process-shared cond-var
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=21422
On 2017-12-25 17:38, Florian Schmidt wrote:
> On Wed, Dec 20, 2017 at 10:25:33PM +0100, Aurelien Jarno wrote:
> > ...
> > I have also tested that the problem is still present in upstream git
> > HEAD.
> >
> > It looks to me the best is to take this issue upstream. Do you want me
> > to forward your bug report and your example in the upstream bugzilla [1]
> > or do you prefer to do it yourself?
Sorry I haven't got the time yet to forwarded upstream
> despite me doing an honest search for an already reported bug like
> this before, i did not find this one, but it seems to address the same
> problem:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21422
>
> it is marked as INVALID with the explanation that there are no
> "robust" variants of the pthread-condition variables.
Indeed this is clearly the same bug. I am marking this debian bug as
forwarded to the upstream one.
> torvalds suggestion mentions catching signals, but as i exlpained this
> is not really an option for us (and does also not work if the waiter
> is killed by SIGKILL e.g. by the OOM killer...).
> the other suggestion is to use other non-blocking synchronization
> methods such as C11 atomics.
>
> and further down it was also suggested to directly use linux' futex
> operations.
>
> thats what i actually did in the last week: signal my "subscribers" via
> a FUTEX_WAKE and by using non-blocking atomic memory ops. it works and
> will probably yield much better real-time behaviour (not yet tested).
>
> still i had to implement it for our system and my guess is that it
> might break other in-production systems (because they erroneously
> rely on what is considered to be not-required behaviour).
Indeed, looking at the bug, it really appears that things won't change
unless POSIX changes. It also means that this behavior will become
standard among distributions while they switch to glibc 2.25 or later.
> so maybe debian should at least make an explicit warning when
> installing glibc >= 2.25?
Debian should make sure this change doesn't break any software we ship
in the archive. As for 3rd party software, I guess we can add a note in
NEWS. I don't think we should do more as most Debian users won't really
understand what condvar or mutex refers to.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: