KSyCoca, Thread safety, and Cache invalidation

[Ivan Čukić]

> 7. the gui thread listens to dbus and sends a signal to the other threads?

It can not send signals since those are not loopy threads.


There is no need for a lot of locking if you put one instance of
KSycoca. You could do something like this (class names are not real :)
):

class MainThread {
    std::shared_ptr<KSycoca> m_ksycoca;
}

std::shared_ptr<KSycoca> MainThread::sycoca() {
    {
        lock_guard...
        return m_ksyscoca
    }
}

updateSyCoca() {
    // create a sycoca instance
    auto tempKSycoca = std::make_shared...;

    // do whatever with tempKSycoca

    {
        lock_guard...
        std::swap(tempKSycoca, m_ksycoca);
    }
}

This way, all the currently queried runners will use the non-updated sycoca.

The main thread will update it, and when it is loaded, it will safely
swap the two. Any runner that calls the MainThread::sycoca() after
that will be using the updated version.

Locked code contains only very cheap operations - construction of a
shared_ptr, not the containing class; and for swapping two
shared_ptrs.

Cheers,
Ivan

On 13 June 2015 at 04:04, Sebastian Kügler <sebas at kde.org> wrote:
> On Saturday, June 13, 2015 02:04:03 Vishesh Handa wrote:
> [...]
>> 3. The gui thread on receiving the dbus signal updates its db as well
>> as the database of all other threads. This is slightly complex and
>> would require locking code similar to (2) since the other threads
>> could be in the process of using KSycoca.
> [...]
>> I'm not quite sure on how to go about this. Do you have any
>> suggestions? I'm leaning towards (3), but the locking code is scary.
>
> 7. the gui thread listens to dbus and sends a signal to the other threads?
> --
> sebas
>
> Sebastian Kügler    |    http://vizZzion.org    |     http://kde.org
>



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun