Making Access to project configuration threadsafe

David Nolden david.nolden.kdevelop at art-master.de
Tue May 29 22:21:02 UTC 2007


On Tuesday 29 May 2007 23:36:14 Kris Wong wrote:
> > Sounds like a plan, so we'd change from
> >
> > KSharedConfig::Ptr projectConfiguration();
> >
> > to
> >
> > KConfigGroup projectConfigurationGroup( const QString& );
>
> If only it were that easy. ;)
>
> In looking at KConfigGroup, it appears to be implicitly shared.  Not
> only is it implicitly shared, but it maintains a pointer to its master
> configuration file, which is where it actually reads and writes from.
> This makes it basically useless for our purposes.  I think we may end up
> having to do something similar to the following:
>
> typedef QMap<QString, QString> KConfigEntryMap;
>
> KConfigEntryMap projectConfigurationGroup( const QString& );
>
> Although the implementation for this isn't particularly complex, it
> would require us to wonder a bit off the beaten path as far as the
> configuration stuff goes.  If that is not the route we want to take, we
> may want to present the issue on kde-devel.
>
> Kris Wong

What if you'd use a special shared pointer that included a locking-mechanism? 
See "plugins/teamwork/lib/network/safesharedptr.h"

You could use "SafeSharedConfigPtr projectConfiguration();"

SafeSharedConfigPtr would be a class that safely cares about 
reference-counting of an object accessed by multiple threads. It can be 
casted to another type, SafeSharedConfigPtr::Locked, to lock the object and 
actually get access.

Whenever a thread needs to access the configuration, it could 
call "SafeSharedConfigPtr::Locked config = mySafeSharedConfigPointer;"

"config" could then be used like a usual shared pointer.

As soon as "config" is destroyed, the mutex is automatically unlocked.

That's how I handle multithreading in the teamwork-part. It's very safe. 
However some wrapper for KSharedConfig would need to be created that 
implements "SafeShared" instead of just "KShared".

Just wanted to give you some inspiration on another way, that would be safe 
and have good performance, to handle multithreading.

greetings, David





More information about the KDevelop-devel mailing list