This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why does rwlock prefer readers by default?
- From: Rich Felker <dalias at libc dot org>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Sat, 24 May 2014 14:21:07 -0400
- Subject: Re: why does rwlock prefer readers by default?
- Authentication-results: sourceware.org; auth=none
- References: <1399458831 dot 32485 dot 12625 dot camel at triegel dot csb> <20140507185121 dot GZ26358 at brightrain dot aerifal dot cx> <1399493345 dot 32485 dot 15258 dot camel at triegel dot csb> <20140524152618 dot GA7647 at domone dot leoexpresswifi dot com> <20140524154842 dot GR507 at brightrain dot aerifal dot cx> <20140524163306 dot GA21891 at domone dot leoexpresswifi dot com> <20140524165545 dot GU507 at brightrain dot aerifal dot cx> <20140524171331 dot GB21891 at domone dot leoexpresswifi dot com>
On Sat, May 24, 2014 at 07:13:31PM +0200, OndÅej BÃlka wrote:
> > > > > To detect these you use bloom
> > > > > filter: split counter to 8 8-bit counters, for each rwlock randomly generate
> > > > > mask which counters it uses and check if all these counters are zero then yield.
> > > >
> > > > I don't see how this is better than choosing a single-bit mask.
> > > > Multiple bits just makes it more-likely to prefer a reader when you
> > > > shouldn't.
> > > >
> > > A problem is how you clear mask when you stop using one lock.
> >
> > I don't follow.
> >
> So let lock A have mask 1, lock B 2. You do
> lock(A); assert(mask == 1);
> lock(B); assert(mask == 3);
> unlock(A);
> Now how you set mask on unlock?
I meant having each rwlock inc/dec exactly one 8-bit counter. This
would be a "1 bit mask" determining which counters it uses, although
obviously a mask is not the best way to implement it then.
>
> > > > > There is techical problem that if a counter reaches 255 we could not
> > > > > decrease/increase it but it should not happen in practice.
> > > >
> > > > What do you do when it does?
> > > >
> > > Keep that 255, it only causes prefering readers for that thread.
> >
> > In that case what happens when you decrement? You can reach 0 when you
> > still hold a read lock, and then calling rdlock again will deadlock
> > (attempting to prefer a writer) rather than allowing you to obtain the
> > lock recursively.
> >
> No, as I wrote you keep that on 255 on decrement.
I missed that. Indeed having a saturated/sticky 255 will avoid the
problem, albeit leaving you stuck with behavior that prefers readers.
I think it works at least "acceptably".
As an aside: it does increase cost mildly. Readers now have to access
TLS, which is expensive on some archs. I'm not claiming this is a
strong enough reason not to make these changes, but it's something to
weigh in the decision.
Rich