I think it should work now. I removed the MutexLocker from the inside of determineUri().
- Vishesh Handa On Sat, May 29, 2010 at 7:32 PM, Vishesh Handa <[email protected]> wrote: > > 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 >> > >
removeProxyPatch6
Description: Binary data
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
