Tile manager and Mutex and desinging for threading

[Cyrille Berger]

On Monday 04 June 2007, Boudewijn Rempt wrote:
> On Monday 04 June 2007, Cyrille Berger wrote:
> > Hello,
> >
> > I have been doing some benchmark on the the tilemanager of Krita2. And it
> > appears (with callgrind and sysprof) that the calls to
> > QMutex::lock/unlock are quiet costly. Especially that, currently, for
> > each call to the data manager, we end up making around 3 or 4 calls (and
> > to achieve that, I have reduced the number of mutex, one safely by using
> > only the bigKritaLock in the tiledatamanager, and one more dangerously by
> > removing the locks in KisTile).
>
> I didn't know we had a Big Krita Lock :-).
oh :) I thought it was you behind it :) but looking at the log it looks it's 
Bart's hand behind that big lock :)

> > And looking at the call graph, no matter what you do, each time you want
> > to access the tile manager, very soon, the whole datamanager is locked.
>
> Well, that's just plain bad -- it shouldn't be necessary at all to lock the
> entire datamanager when writing to a tile, and it shouldn't be necessary at
> all to lock the datamanager when reading. If databases manage per-record
> locking, we can surely manage per-tile locking -- it's the same problem.
I guess they don't use QMutex :D it's much slower than pmutex but QMutex does 
more, like allowing lazy people to relock a mutex from the same thread.

> > So I
> > was wondering if having one lock in the datamanager, locking it each time
> > before we request something from it.
>
> That would make it impossible to update parts of the image in different
> threads -- 
no

> something I definitel want.
so do I,.

> What I want to end up with, and the  
> beginning of that exists in the setRegionsOfInterest method of
> KisProjection, is to be able to have the projection recomposite the visible
> areas immediately and recomposite the invisible areas in the background (so
> the complete image can be ready for the histogram when it needs to
> recompute itself, for instance).
that would be cool :)

But having one lock on the datamanager won't prevent that. It would only 
prevent two threads to "fetch" a tile at the same time. I mean, what would 
happen:
t= 0
thread #1 : fetch tile 1
thread #2 : wait
t= 1
thread #1 : play with tile 1
thread #2 : fetch tile 2
t =2
thread #1 : fetch tile 3
thread #2 : play with tile 2
etc...

(and it would be even cooler if there is a dedicated thread for the swapping 
and unswapping of tiles, but that's an other topic I will leave to 
datamanager hacker)


-- 
Cyrille Berger