[Buildbot-devel] multiple readers/single writer lock

A.T.Hofkamp a.t.hofkamp at tue.nl
Wed Jul 2 09:17:48 UTC 2008


Hello all,

In my setup, several .tar.gz files are built from one svn working copy. Each 
has its own builder. To prevent many equal svn working copies, I have made a 
small 'working-copy' management script that manages several working copies in 
a branch/revision directory structure.

Each builder queries a particular branch/revision combination, and the script 
adds that to the directory structure if it doesn't exist (and else, does nothing).

There is also a builder that removes old working copies.

(The master and all slaves run at the same machine, so they can exchange data 
via the file system.)


At the moment, I have an exclusive master access lock on the working copies 
for each builder, so the same branch/revision combination is never queried 
twice concurrently, and also to prevent removal of a working copy by the 
cleanup builder while a .tar.gz file is being constructed.


This is working quite nicely, but not very fast. The exclusive access forms a 
bottle-neck in the builds.

However, since the working copies are not modified by the build process, I'd 
like to have several .tar.gz builds being executed concurrently, sharing 
working-copies. However, the cleanup builder should only run when no other 
builder is active, in other words, I need a multiple readers - single writer lock.


Can this be done in 0.7.7 ?

I looked at the maxCount property of the locks, and they seem to be useful 
only for limiting the number of builders/slaves on a per-builder/per-slave 
basis, while I'd like to have intra-builder exclusion locking.
(ie "maximal 3 builders with name 'x' AND 5 builders with name 'y'" rather 
than "1 cleanup builder OR 2 (in my case) .tar.gz builders" which I'd like to 
have).

Is my interpretation of the maxCount property correct?

If no, I'd be very happy :) , and the remainder of this post is unneeded.

If yes, I can have a go at improving the situation.

I have considered an alternative interpretation of the count towards 'weight'. 
A lock can take at most x units weight. Each builder adds some weight, thus 
limiting the total number of builders. While this would solve my problem, I 
fear it also makes my interpretation of the existing semantics impossible.

A solution would be to add the weight concept to the current semantics. Then 
both ideas can be expressed. To me, it doesn't seem a clean solution, too many 
different numbers.

How does the list consider this?



Albert




More information about the devel mailing list