Making Access to project configuration threadsafe

[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".

This is very similar to the mutex locker concept, only a little less direct.
We could do something along the lines of a new class: ProjectConfigLocker and
use it as such:

// pretend IProject is an instance, obviously.
ProjectConfigLocker l(IProject*);
KSharedConfig::Ptr cfg = IProject::projectConfiguration();
// cfg can now be used safely.

We could then add debugging code to Project::projectConfiguration that
would ensure the current thread has the mutex locked.  This would require
that developers who needed the project configuration would have at least
some base base knowledge of locking, though.

Kris Wong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3634 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070529/412392d7/attachment.bin>