Deform brush and deadlocks

Mon Jun 29 17:13:06 CEST 2009

Well, i can't join your conversation fully right now. But there are some my
ideas:

1) We won't prevent two write iterators from writing to different lines with
exclusive access if we make a good recursive(!) read-write lock with
relocking for different type of access ability. It'll create quite a big
overhead, but it'll work.

2) I think we need locking in general. And we shouldn't (or can't) leave it
to the upper level. Example: deform-brush case. I don't know how it happened
exactly (didn't have time yet to investigate properly), but merging and
previewing was started in parallel with brush working. I think it's logical,
that merging should wait until a brush finishes it's work. Or we could allow
it to show half-done work? I think this is main question of our discussion.
We don't have any concurrency between painting tools (at least now), all
races happen while previewing. If we allowed layer-updater thread to show
user half-done work, the system would be much simplier.
In such a case we'd need write-locks only.

3) At the moment, i think the best variant is (if we decide to do locking at
all):
- Leave exclusive locks.
- Introduce a rule, that one thread won't have more than one read and one
write iterator simultaneously.
- Rewrite iterators (i planned it already, but i planned to do it after
mipmapping) is such a way, that it releases ALL cached tiles when goes to
sleep. In such a case we lower deadlock probability, but we don't solve the
problem itself, because a thread still can have locked tiles on entering the
sleep. It can be solved by joining together read and write iterators (or
their caches, or even more - per thread storage of locked tiles cache), but
there are some issues, e.g. we can't unlock a tile that we were writing to
if we can't get an access to some other tile for read. If we do - it'll be
an equivalent to no locking at all.

4) Locking with QRect.
If a tool would lock entire rect it needs before starting work - it would be
great! It would solve deadlock problem completely - as "Circular
wait<http://en.wikipedia.org/wiki/Circular_wait>condition" would be
removed. But in such a case we should rewrite entire
Krita codebase, shouldn't we?

PS:
Btw, locking rects would improve caching too. It could be based on rect
iterators... Just add random and line accessing abilities to
KisRectIterator... I like this idea... But it's too expensive...

[1] http://en.wikipedia.org/wiki/Circular_wait

On Mon, Jun 29, 2009 at 6:16 PM, C. Boemann <cbr at boemann.dk> wrote:

> [15:55] <boemann> boud: you know, if we make write access exclusive we
> also prevent two write iterators on say different lines from working
> [15:56] <boemann> as access is per tile and not per pixel
> [15:56] <-- fyanardi has left this server (Read error: 54 (Connection reset
> by
> peer)).
> [15:56] <boemann> that might break some algorithms
> [15:56] <boud> yes, indeed
> [15:57] <boemann> on the other hand two tiles accessing the same tiles
> shouldn't be allowed from a more top down perspective
> [15:57] <boud> better put that in a mail so dmitry sees it too
> [15:57] <boemann> i've told him before
> [15:57] --> fyanardi has joined this channel (n=edi at 116.197.231.178).
> [15:58] <boud> not sure what you mwith two tiles accessing the same tiles
> [15:58] <boemann> two iterators
> [15:58] <-- slangkamp has left this server ("Konversation terminated!").
> [15:58] <boemann> now threads
> [15:58] <boemann> sorry
> [15:58] <boemann> on the other hand two threads accessing the same tiles
> shouldn't be allowed from a more top down perspective
> [15:59] <boud> yes
> [15:59] <boud> so two iterators in the same thread shouldn't be a problem
> [15:59] <boemann> i think that must be up to the algorithm writer
> [16:00] <boemann> but the example of drying filer  together with user
> painting is a problem because there it isn't easy to tell the user not to
> draw
> [16:01] <boemann> on the other hand we don't want the drying filter to lock
> everything
> [16:01] <-- burmas has left this channel ("Konversation terminated!").
> [16:02] <boemann> so for cases where multiple operations are taking place
> at the same time we do need some kind of locking
> [16:02] <boemann> but we don't need it for cases where a single task is
> divided between threads
> [16:03] <boemann> and right now the only multiple operation usecase i can
> come up with is drying+user painting
> [16:04] <boud> yes... recomposition only needs read access and can wait
> until the user is done painting on a tile.
> [16:04] <boemann> yes
> [16:05] <boemann> i think that maybe if we in the future needs multiple
> operation locking we should then come up with another api
> [16:05] <boemann> something on top of the timemanager
> [16:05] <boemann> tile
> [16:06] <boemann> like a way to say: hey i'm locking this qrect for a while
> [16:06] <boud> yes
> [16:06] <boud> although that is more or less what you get when you lock a
> tile :-)
> [16:07] <boemann> true but we have just established that we can't in
> general lock tiles
> [16:07] <boemann> besides locking tiles adds overhead for no good reason
> in general
> [16:08] <boemann> only trouble with a new api is that current tools don't
> know about it and would probably need to be modified
> [16:08] <boemann> for that reason doing it in the tilemanager would be nice
> [16:09] <boud> besides, we don't want to bother filter or paintop writers
> with
> explicit locking or unlocking
> [16:09] <boemann> right
> [16:09] <boemann> idea:
> [16:10] <boemann> what if we provide a method:
> paintdev::setLockOtherUsers(bool)
> [16:11] <boemann> that would signal the taskmanager that tile access by
> this thread is exclusive
> [16:11] <boemann> other users of the paintdev would be locked out of the
> tile whenever the exclluve tile has a lock on it
> [16:11] <boemann> but in general tiles are not locked
> [16:12] <boemann> this exclusiveness can then be used by drying filter like
> stuff
> [16:12] <boud> I'm not sure I like that idea
> [16:12] <boemann> why
> [16:13] <boud> well, I might not get it, but I think it's too explicit
> [16:13] --> DetroitLibertyPe has joined this channel
> (n=Parrot_T at 209-255-22-2.ip.mcleodusa.net).
> [16:13] <boud> and we would have to mutex around the getter for that paint
> device
> [16:13] <-- DetroitLibertyPe has left this channel.
> [16:13] <boud> I'm not sure I've got the real requirements clear, though
> [16:13] <boemann> we would have to do that with any locking mechanism
>
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090629/b0fdf051/attachment-0001.htm 