Tile manager and Mutex and desinging for threading
Cyrille Berger
cberger at cberger.net
Mon Jun 4 22:43:40 CEST 2007
> > 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...
and you are right :) But multipliying the locking is not necesseraly a good
idea, as it can result in deadlocks.
> > 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.
yes, after all, multithreading for projection can be one thread to do the
projection work for one layer, but anyway, we want multiple thread to work on
the same layer for filtering...
> > 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?
I don't think one lock on the datamanager lock the entire paint device, as you
only need to "speak" with it when fetching a tile. So right, one lock on the
tilemanager, serialize access to the swapfile, while one lock to the
datamanager serialize getting new tiles.
> 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.
yup. I hope Bart is taking notes of cool stuff to do :D
--
Cyrille Berger
More information about the kimageshop
mailing list