[Nepomuk] Nepomuk Core - Questions & Patches

[Vishesh Handa]

On Sat, May 29, 2010 at 7:17 PM, Sebastian Trüg <trueg at kde.org> wrote:

> On 05/29/2010 03:34 PM, Vishesh Handa wrote:
> > On Sat, May 29, 2010 at 5:46 PM, Sebastian Trüg <trueg at kde.org
> > <mailto:trueg at kde.org>> wrote:
> >
> >     Hehe, this does not help at all. Think about it: in my example there
> are
> >     2 Resource instances involved. Thus: 2 mutexes which are locked
> >     independent of each other. :)
> >     The mutex is already there in ResourceData. It simply needs to be
> locked
> >     in Resource instead of ResourceData::determineUri.
> >
> >
> > Uhh I'm confused. Why don't you handle the multi-threading?
>
> Sure, I can do that. :)
>

Wait! Please don't. Let me try. I understand it now. (I think)


>
> > I should really learn about multi-threading. If you have a couple of
> > spare minutes could you explain why my method won't work?
> >
> > My rationale -
> >
> > Thread 1 :
> > Resource r1("foo");
> > r1.property( nao:numericRating )
> > -> the mutex is locked
> > -> performs whatever and determines the uri
> >
> > Thread 2 :
> > Resource r2("foo");
> > r2.setProperty( whatever )
> > -> the mutex can't get locked so it waits till it does
> > -> mutex now locked. Thread 1 should have determined the uri by now
> > -> perform operation
>
> Simple: r1 and r2 have different mutex intances. Thus, locking one does
> not prevent the other from being locked. The idea is that both threads
> need to lock the same mutex. And that is only possible if the mutex is
> stored in ResourceData.
>
>
Oh. Of course. Thanks for explanation. :-)

- Vishesh Handa

Cheers,
> Sebastian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100529/72815f0a/attachment.htm