Some more experiments

[Boudewijn Rempt]

On Thursday 07 June 2007, Schleimer, Ben wrote:
> Hi Boud,
>    I've been reading yours and Cyrille's emails about QMutex and locking
> and I had a brainstorm that maybe it would be better not to use locking at
> all. Isn't the only times multiple threads are going to try to modify the
> different tiles is when long jobs are running on them? Like resizing or
> filtering or transforming? Why not divide up all of the target tiles of a
> job into different groups and give each group to a thread. Then there won;t
> be any contention.

There are two problems: we've hidden the tiles behind an iterator interface to 
make coding a lot simpler, and, for composition or other operations that use 
two paint devices, it's possible that the paint devices don't have the same 
origin, which means that the tile boundaries don't coincide.

On the other hand it would be possible to give core components like 
KisProjection and the KisThreadedApplicator some knowledge of the underlying 
system that makes it possible to work on tile boundaries. Not without 
complications, of course -- for convolution operations it's necessary to give 
read access to the pixels surrounding the write area.

But the big locking problem right now is in a different place: there's a 
singleton, KisTileManager that is responsible for the (virtual) memory 
management of the tile data. Every tile access needs to ensure that the tile 
data is not swapped out, every tile creation needs to get a chunk of memory 
from a common pool -- etc. All this is, right now, locked too. And that's 
what we're going to have to change first.

> If thats not possible, you might want to explore using atomic variables and
> atomic-increment-and-check instead of QMutex. QMutex is good if there is A
> LOT of threads competing for the same resources at a time but it's overkill
> if there is only a couple...

That's a good idea for the tiles themselves -- we'll have to investigate that. 
Thanks!

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