--===============1924728740==
Content-Type: multipart/signed;
  boundary="nextPart10461489.cnXPLWfFze";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart10461489.cnXPLWfFze
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
make coding a lot simpler, and, for composition or other operations that us=
e=20
two paint devices, it's possible that the paint devices don't have the same=
=20
origin, which means that the tile boundaries don't coincide.

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

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

> If thats not possible, you might want to explore using atomic variables a=
nd
> 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 overki=
ll
> if there is only a couple...

That's a good idea for the tiles themselves -- we'll have to investigate th=
at.=20
Thanks!

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart10461489.cnXPLWfFze
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGa8lbdaCcgCmN5d8RAkwtAKDhA/gpPgvXsh9U6MF65X3DoDgh5gCdEuHM
k50NcMWw9mOyn4ptVqeg7q8=
=5a82
-----END PGP SIGNATURE-----

--nextPart10461489.cnXPLWfFze--


--===============1924728740==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

--===============1924728740==--