Threadsafe project model

David Nolden zwabel at googlemail.com
Thu Jul 15 22:30:20 UTC 2010


Locking within every single sub-function of the project-model still
wouldn't solve consistency-problems, like for example:

thread A: item.setParent(someting)
thread B: item.setParent(someThingElse)
thread A: ASSERT(item.parent() == someting) <- BANG
Or even worse, one thread could delete the imem.

If you simply define that the project-model belongs to the foreground,
you can use the foreground lock. In order to have an advantage, the
parsers need to be designed to only lock it for short times, but
during those times, the state is guaranteed to be as expected, without
strange interactions with other threads.

Example:

CMakeManager::parseTarget() {
Do complicated and slow stuff, build duchain, resolve variables, regexes, etc.

QString targetName = blabla;
QStringList fileList = blub;

ForegroundLock lock;
-> Allocate/update project items for this target only, but do nothing
slow/complicated.
}

Greetings, David




More information about the KDevelop-devel mailing list