re: serializing token

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hmmm... Interesting and neat code! However, doesn't this suffer from the 
:ABA problem? Couldn't "vp" here get removed and then something new (but 
:with the same address as "vp") gets put back in all before  
:lwkt_gettoken(vlock) returns from a blocking? 

    Nope.  The placemarker can only be touched by the procedure that added
    it in the first place, so the placemarker becomes a 'stable' island
    within the list that stays put.

    So the conditional after the gettoken(&vlock), which rechecks the 
    validity of vp, is sufficient:

                if (slowfunc) {
                        lwkt_gettoken(&vlock, vp->v_interlock);
                        if (vp != TAILQ_PREV(pvp, vnodelst, v_nmntvnodes)) {
			...

    pvp is the placemarker, which is guarenteed to not be messed with by
    anyone else.  So the conditional is checking that the vnode being scanned,
    vp, is still where we expect it to be in the list after we have obtained
    vlock.

:I didn't look closely at the allocator implementation, but this is 
:especially susceptible if your allocator's free list is LIFO... You 
:free(vp) and then vp = malloc() in quick succession, then vp's address 
:won't really change.
:
:Dave.

    True, but here we are saved by the fact that vnodes are always added
    to the tail of the mountlist.   If a vnode is freed and recreated, it
    will not be found in the same place on the mountlist (it will not be
    found behind pvp, it will be found somewhere else).  So the placemarker
    algorithm kills two birds with one stone.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>