On Wed, Nov 26, 2014 at 1:23 PM, John Harrison <John.C.Harrison@xxxxxxxxx> wrote: >> This needs locking. It might work as-is but it's definitely too tricky to >> be worth it. > > The manipulation of the list is locked, only this test is unlocked. Do you > really need to lock when testing for empty? Nothing can be removing items > from the list although something could be asynchronously adding them. If the > 'head->next == head' test goes wrong because head or next is being written > to, it can't deference a dodgy pointer. It can only return an incorrect > 'empty' in which case the clean up is delayed until later. An incorrect > 'not-empty' is not possible. The problem is not that it's broken but too tricky. And nothing in either the commit message nor a code commit explains and justifies this. Of course every time I stumble over this I can think hard for a while and convince myself that it works, but GEM is already littered with such inherent complexity, so adding accidental complexity for locking tricks when they're not needed is a bad move. Since we don't actually need this in current code I'll drop it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
