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 >> > >
