Torvald Riegel wrote:
> > Are you suggesting that the pthread_yield manual page is wrong? Or that
> > some warning should be added to it? I'm sure Michael Kerrisk will accept
> > inputs.
>
> I don't think it's necessarily wrong, but if there's no actual run queue
> because you have more or the sa
On Fri, 2017-01-06 at 00:11 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > The problem here is: it's a unit test. If it fails, I don't want to search
> > > for bugs in the condition variable subsystem, semaphore subsystem, AND the
> > > lock subsystem. I want the test to rely essentially
Torvald Riegel wrote:
> > The problem here is: it's a unit test. If it fails, I don't want to search
> > for bugs in the condition variable subsystem, semaphore subsystem, AND the
> > lock subsystem. I want the test to rely essentially only on the lock
> > subsystem.
>
> locks are the wrong mecha
On Thu, 2017-01-05 at 19:42 +0100, Bruno Haible wrote:
> Torvald Riegel wrote [in private email, should have CCed bug-gnulib]:
>
> [about the use of a lock in 'struct atomic_int' in test-lock.c:]
>
> > > The delivered code, with a lock, is correct, however, right?
> >
> > Not quite, unfortunatel
Torvald Riegel wrote [in private email, should have CCed bug-gnulib]:
[about the use of a lock in 'struct atomic_int' in test-lock.c:]
> > The delivered code, with a lock, is correct, however, right?
>
> Not quite, unfortunately, because locks do not make any guarantees
> regarding fairness. Th
