shared lwkt locks

[Alex Merritt]

I'll take a look further to see what is going on. I suspect the use of a
shared lock might not be the right approach for what I am doing.

-Alex

On Thu, Jul 16, 2015 at 9:42 PM, Matthew Dillon <dillon at backplane.com>
wrote:

> That warning is in comments, it's documenting the fact that
> vm_object_drop() might be called reentrantly due to potentially being
> locked shared.
>
> -Matt
>
> On Thu, Jul 16, 2015 at 9:40 PM, Matthew Dillon <dillon at backplane.com>
> wrote:
>
>> You are doing something more than what you coded above and it is causing
>> the object's hold count to go negative on the second drop.  That particular
>> panic is not related to the token itself.   It looks to me like the object
>> must have been dropped more times than it was held.
>>
>> -Matt
>>
>> On Thu, Jul 16, 2015 at 6:25 PM, Alex Merritt <merritt.alex at gmail.com>
>> wrote:
>>
>>> Matt,
>>>
>>> Thanks. I am working with the locks in the order as you described. I am
>>> specifically trying to understand if the order also applies to shared lock
>>> acquisitions, as I am experiencing a panic when I drop a lock the second
>>> time, after having performed two shared acquisitions:
>>>
>>> vm_object_hold_shared(A)
>>> vm_object_hold_shared(A)
>>> vm_object_drop(A)
>>> vm_object_drop(A) // <-- panic
>>>
>>> The panic is here: http://bxr.su/DragonFly/sys/vm/vm_object.c#332
>>>
>>> Is this panic expected behavior (i.e. does a release relinquish any
>>> number of prior shared lock acquires to a token)?
>>>
>>> The location of the warning in comments I am referring to is here:
>>>
>>> http://bxr.su/DragonFly/sys/vm/vm_object.c#320
>>>
>>> -Alex
>>>
>>>
>>> On Thu, Jul 16, 2015 at 5:54 PM, Matthew Dillon <dillon at backplane.com>
>>> wrote:
>>>
>>>> Lock releases must match lock acquisitions.  lwkt_tokens have an
>>>> additional requirement that lock releases must be performed in exactly the
>>>> reverse order as the acquires.  So if you acquire A, B, C, B, X, Y  you
>>>> have to release in reverse, Y, X , B, C, B, A.
>>>>
>>>> Shared tokens are very dangerous and must be used carefully.  The
>>>> vm_object code is the most complex code in the kernel that uses shared
>>>> tokens, and as you can see by reading it, it can get nasty because a
>>>> particular token cannot mix shared and exclusive use in the same thread.
>>>>
>>>> I'm not sure which warning you are talking about, where in
>>>> vm_object_drop() ?
>>>>
>>>> -Matt
>>>>
>>>> On Thu, Jul 16, 2015 at 5:31 PM, Alex Merritt <merritt.alex at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does releasing a lwkt_token release all prior gettoken_shared
>>>>> invocations to that lock, or is one required to perform reltoken as many
>>>>> times as you've performed gettoken_shared? There is a warning in
>>>>> vm_object_drop that the lock may be shared -- I was wondering what exactly
>>>>> that warning is meant to warn against. Apologies if the answer is apparent
>>>>> somewhere.
>>>>>
>>>>> Thanks,
>>>>> Alex
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20150716/9834b046/attachment-0003.htm>