> I recently read an article how KDevelop handles threading and that got
> me thinking. As far as I understand Pier currently uses a global lock
> for all write operations (where #isView returns false). All good an
> fine so far. But shouldn't this be a a read-write lock?
Yes, this is correct.
> Imagine the
> following scenario:
>
> - a view command is executed, is starts to read some objects, iterates
> over some objects
> - the current process is unscheduled
> - a new process is with a write command is scheduled, it executes to
> completion
> - the original view command is scheduled a again but it has
> inconsistent information, eg the parent of an already read structure
> has changed
True, this might happen. Since write operations are rare compared to
read operations the problem is very unlikely to occur though. Moreover
a single edit operation is unlikely to affect a random viewer. In the
very unlikely event the viewer might get an inconsistent view. So
what? In the absolutely worst case the viewer might get an exception.
I have never seen such a situation though.
> A read-write lock should not affect performance because it allows
> multiple concurrent readers.
It is certainly feasible, but is it worth the trouble to add a read-
write lock to avoid this rare situation?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Locked
