On Sat, May 29, 2010 at 7:17 PM, Sebastian Trüg <[email protected]> wrote:
> On 05/29/2010 03:34 PM, Vishesh Handa wrote: > > On Sat, May 29, 2010 at 5:46 PM, Sebastian Trüg <[email protected] > > <mailto:[email protected]>> 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 >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
