[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test-lock hang (not 100% reproducible) on GNU/Linux

From: Pavel Raiskup
Subject: Re: Test-lock hang (not 100% reproducible) on GNU/Linux
Date: Wed, 04 Jan 2017 09:04:16 +0100
User-agent: KMail/5.3.3 (Linux/4.8.15-300.fc25.x86_64; KDE/5.27.0; x86_64; ; )

On Wednesday, January 4, 2017 12:43:17 AM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > POSIX says (for pthread_rwlock_wrlock()):
> > 
> >     Implementations may favor writers over readers to avoid writer 
> > starvation.
> > 
> > But that's too far from 'shall favor' spelling.
> You must be looking at an old version of POSIX [1]. POSIX:2008 specifies [2]:
> [TPS] If ... the threads involved in the lock are executing with the 
> scheduling
>       policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire 
> the
>       lock if a writer holds the lock or if writers of higher or equal 
> priority
>       are blocked on the lock; otherwise, the calling thread shall acquire the
>       lock.
> That states pretty clearly that the goal is that if both threads have equal
> priority, the "writer" thread gets the rwlock.

Ah, I was looking at old specification.  Those SCHED_FIFO (etc) seem to be
real time options disabled by default, thus also in test-lock.c, but in
[2] there's also:

    The calling thread acquires the read lock if a writer does not hold the
    lock and there are no writers blocked on the lock.

This sounds fair..  Thanks for pointing that out!

Remaining questions:

Can we assume all systems supporting pthreads are conforming to this
specs?  That was pretty big (and pretty recent) change of specification.

If we really want to test _this_ behavior (writers preferred over readers,
i.e. no rdlock when at least one wrlock acquired), shouldn't we apply
something like the patch from [3]?  Than that test would be detrerministic for
everybody, now it is really matter of luck.

Can we define (documment) what is the real issue we try to test by test_rwlock?
I mean:  We should define what "fair" scheduler means, and fail if that's not
truth ... not hang.   Now the definition of "fair" means "test ends in a finite

Can there be a timeout, at least?

Simply, after spending some time on this issue (and I'm not the first
one), I'd like to see some fix in gnulib so nobody else in future will
face similar issues.  Any other suggestion is welcome, I can possibly
try to have a look at the implementation.

> > It might be bug in libpthread, too, but based on the POSIX specs and manual
> > pages, I am not sure whether this might be actually considered a bug.
> At least a quality of implementation issue, IMO.

Agreed.  I'll try ask glibc guys, or kernel guys (Fedora/RHEL).

[3] https://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00024.html


> Bruno
> [1] 
> http://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html
> [2] 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]