branches/work/koffice-feature-tiles-ng/krita/image

[Dmitry Kazakov]

>
> 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.
Hughes<http://labs.trolltech.com/blogs/author/brad/>succeeded 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090627/7b24102d/attachment.htm