[Yum-devel] locking

[Florian Festi]

seth vidal wrote:
> On Thu, 2008-02-21 at 16:17 +0100, Florian Festi wrote:
> 
>> If it gets implemented that simple we can get deadlocked quite easily.
>>
>> instance 1: lock repo1
>> instance 2: lock repo2
>> instance 1: lock repo2 -> wait
>> instance 2: lock repo1 -> wait -> deadlock
> 
> 
> No.
> instance 1: lock repo1, do what you have to do, unlock repo1
> instance 2: lock repo2, do what you have to do, unlock repo2
> instance 1: lock repo2, wait until instance 2 unlocks, continue.
> 
> How are we deadlocking there?
> 
> You're thinking of the lock being for the entire runtime of the program,
> I'm thinking of the lock being for the time during which we are
> WRITING/downloading info.

May be I do not understand the problem you want to solve but what does it 
help if we lock the repos for writes only? I guess the sqlitedb will be very 
unhappy if you replace the file is is working on even in read only mode. 
We'd be better off by using filenames containing the SHA1 for the dbs and an 
atomic replace for the repomd file.

As is is very unlikely that two applications will work on two completely 
separate sets of repos it would make more sense to have a global lock that 
can be acquired multiple times for reads and only once for writes (also 
counting the read locks)

Florian