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 <dil...@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 <dil...@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.a...@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 <dil...@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.a...@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 >>>>> >>>> >>>> >>> >> >
