[devel at bb.net] exclusive locks & fairness

[Dustin J. Mitchell]

I think your analysis is correct.

Locks are entirely implemented within a master, which has a good side and a
bad side.  On the good side, it means all the data you need is there,
somewhere in memory.  On the bad side, it means they don't work too well on
a multi-master setup.

I think it would make sense to keep list of lock requests, in order.  In
other words, a new counting lock can't acquire a lock that's already
acquired in counting mode iff there is a pending exclusive lock.

Dustin

On Tue, Nov 3, 2015 at 11:38 PM, Vitali Lovich <vlovich at gmail.com> wrote:

> Hi,
>
> My impression is that there is no fairness for locks currently & that
> exclusive locks can starve.  Is that true?
>
> In other words, if I have job A that acquires a counting lock & job B
> acquires an exclusive lock, job B will correctly wait until A is done.
> However, if job C comes in & it in turn also acquires a counting lock,
> it will continue since it can acquire the lock thus preventing B from
> running.
>
> Assuming my analysis is correct, is anyone aware of an easy way to fix
> this (e.g. via some hook point within buildbot) or where I would even start
> to look for it?
> For example, is there a way to test if anything is waiting to acquire a
> given exclusive lock?  I had a test that just tried to see if it could get
> the exclusive lock but I just realized that’s broken since it basically
> just transforms that lock into an exclusive lock.
>
> Thanks,
> Vitali
> _______________________________________________
> devel mailing list
> devel at buildbot.net
> https://lists.buildbot.net/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/devel/attachments/20151104/a7ad24a4/attachment.html>