Tile manager and Mutex and desinging for threading

[Boudewijn Rempt]

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 :-).

> 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.

> 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 -- something I definitel want. 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).

> Basicaly, three classes are accessing 
> the datamanager: KisPaintDevice, KisTiledIterator and
> KisTiledRandomAccessor.
>
> I am also wondering if giving access to a tile to two threads is a good
> idea. Basically we have three case:
> - read/read two threads are reading the tile
> - read/write one thread is reading while one other is altering
> - write/write two threads are writting
>
> read/read is ok. But the other two are a call to get problems. So do we
> want to allow read/read, or a simple locking of the tile would be enough ?

I want to design to allow concurrent reads as long as there is no write action 
on the tile.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070604/292a94e3/attachment.pgp