Tile manager and Mutex and desinging for threading

[Boudewijn Rempt]

On Monday 04 June 2007, Cyrille Berger wrote:

> oh :) I thought it was you behind it :) but looking at the log it looks
> it's Bart's hand behind that big lock :)

Ever since I discovered the Python GIL I've had a distrust of Big Locks...

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

Well, they probably also have a design where they don't use a single backend 
to store all data; among other things it's why databases have more than one 
swap file, generally speaking.

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

The only thing I need for that to work is to figure out the visible area in 
the canvas widget classes and pass that up to the projection -- and a little 
bit of extra code in KisProjection, but that's not the hard part.

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

Tile manager or data manager? I always confuse these two, too... One lock on 
the datamanager will lock the entire paint device, one lock on the the 
tilemanager will serialize access to the swapfile and to the memory pool for 
tiles, right?

And, yes, a dedicated thread for memory management would be cool. It would 
also be the place to do the compression of (undo) tiles before swapping them 
out.


-- 
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/eb805b74/attachment.pgp