[Nepomuk] Nepomuk Core - Questions & Patches

Vishesh Handa handa.vish at gmail.com
Sat May 29 16:37:09 CEST 2010


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 <handa.vish at gmail.com> wrote:

>
> 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/87c39433/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: removeProxyPatch6
Type: application/octet-stream
Size: 24089 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100529/87c39433/attachment-0001.dll 


More information about the Nepomuk mailing list