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.
- 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
- the original view command is scheduled a again but it has
inconsistent information, eg the parent of an already read structure
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?