Making Access to project configuration threadsafe

[Andreas Pakulat]

On 29.05.07 13:26:57, Kris Wong wrote:
> I haven't look at the API for this at all, but I'll chime in with some
> knowledge on threading and concurrency.
> 
> 1. Reading from an object is never a issue in a threaded environment.
> Writing to an object is where concurrency issues arise.

I'm not sure that reading really is a non-issue, keep in mind that we're
dealing with implicitly shared kconfig objects here. At least thats the
impression that I got from the answers on kde-devel.

> 2. Depending on the nature of how and when the configuration will be
> accessed for reading and writing, there are different ways to handle
> this.  Usually the more assumptions that can be made, the simpler the
> implementation can become.

Writing to the configuration will only be done in the GUI thread, after
doing that the KSharedConfig::Ptr object in Project would get updated to
reflect these changes (that last part is not implemented yet, IIRC). The
writing will happen on a separate KConfig object that is created inside
the KControl Modules which is created from the temp files, those need to
be re-read once the configuration was applied/ok'ed.

> Here are two cover-all-bases approaches for handling this:
> 
> 1. The project only gives out and accepts deep copies of the
> configuration.  It will have one mutex which will be locked for long
> enough to deep copy into another configuration object (in the case of a
> read), or from another configuration object (in the case of a write).
> The down side to this is obvious, it is inefficient.  The upside are
> that it is a simple implementation and not prone to errors. Depending on
> the size of the configuration object and the amount of accesses, it may
> be sufficient.

As the KSharedConfig pointer is supposed to be short-lived and KConfig
is meant to be accessed often (pretty fast in KDevelop3) I think this
could suffice.

> 2. The project has two methods, one which locks a configuration mutex
> and returns a pointer, and one that unlocks it.  It then becomes the
> responsibility of the caller to lock and unlock appropriately.  This is
> obviously more efficient, and more prone to errors and incorrect usage
> scenarios.

Thats exactly what I'd like to avoid, for exactly the reasons you
mention.

Andreas

-- 
Communicate!  It can't make things any worse.