From kde-kimageshop Sat Jun 27 08:00:56 2009 From: Dmitry Kazakov Date: Sat, 27 Jun 2009 08:00:56 +0000 To: kde-kimageshop Subject: Re: branches/work/koffice-feature-tiles-ng/krita/image Message-Id: X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=124615170802319 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1000281118==" --===============1000281118== Content-Type: multipart/alternative; boundary=001485f629a65434c3046d4fdbb7 --001485f629a65434c3046d4fdbb7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > On Friday 26. June 2009 21.08.55 Dmitry Kazakov wrote: > > I don't really know how to solve it yet, but i guess, we should make > > some "locking rules", and follow them... This is the only method of > > getting rid of deadlocks i know. At least linux kernel uses it and it > > works [1]. > [] > > If you have some comments or suggestions - YOU ARE WELCOME! :) > > Lock free programming in Qt is possible using the QAtomic set of classes in > Qt. QAtomicInt api docs; http://doc.qtsoftware.com/latest/qatomicint.html > This will give a nice read; > http://labs.trolltech.com/blogs/2008/10/22/a-never-ending-struggle/ > Thanks! A really nice read! :) He seems to have introduced what is called "Seqlocks" in linux kernel since 2.5. Speaking truly, i can't really see how to adopt it to tiles, as a tile can't be read atomically in one "lock readq ..." instruction. We need to serialize access to the same tile from two different threads. COW can't help us in this situation (only one tile). The only lockless way of serialization i see here, this is Read-Copy-Update (RCU) method of linux kernel. It'd be built on top of QAtomic, but it would introduce tooooo muuuch overhead in our situation as tiles are quite huge (4KiB) The reason why Bradley T. Hughessucceeded with seqlocks his write-access code was encapsulated inside a small function. In Krita case, we write into tiles all over the code, and this very code hasn't been written in assuming that just having been read piece of data is broken and have to be reread again. --- [1] http://en.wikipedia.org/wiki/Seqlock [2] http://en.wikipedia.org/wiki/Read-copy-update -- Dmitry Kazakov --001485f629a65434c3046d4fdbb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday 26. June 2009 21.08.55 Dmitry Kazakov wrote:
> I don't really know =C2=A0how to solve it yet, but i =C2=A0guess, = we should make
> some "locking =C2=A0rules", and follow them... =C2=A0This is= the =C2=A0only method of
> getting rid of deadlocks i know. =C2=A0At least linux kernel uses it a= nd it
> works [1].
[]
> If you have some comments or suggestions - YOU ARE WELCOME! :)

Lock free programming in Qt is possible using the QAtomic set of classes in=
Qt. QAtomicInt api docs; http://doc.qtsoftware.com/latest/qatomicint.ht= ml
This will give a nice read;
http://labs.trolltech.com/blogs/2008/10/22/a-never-e= nding-struggle/

Thanks! A really nice read! :)
He seems to have i= ntroduced what is called "Seqlocks" in linux kernel since 2.5.Speaking truly, i can't really see how to adopt it to tiles, as a tile= can't be read atomically in one "lock readq ..." instruction= .

We need to serialize access to the same tile from two different threads= . COW can't help us in this situation (only one tile). The only lockles= s way of serialization i see here, this is Read-Copy-Update (RCU) method of= linux kernel. It'd be built on top of QAtomic, but it would introduce = tooooo muuuch overhead in our situation as tiles are quite huge (4KiB)

The reason why Bradley T. Hughes succeeded with seqlocks his write-access code was e= ncapsulated inside a small function. In Krita case, we write into tiles all= over the code, and this very code hasn't been written in assuming that= just having been read piece of data is broken and have to be reread again.=

---
[1] http://en.w= ikipedia.org/wiki/Seqlock
[2] http://en.wikipedia.org/wiki/Read-copy-update

--
Dmitry Kazakov
--001485f629a65434c3046d4fdbb7-- --===============1000281118== 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 --===============1000281118==--