[Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops

[Gore, Tim]

Unfortunately Android threads do not support cancel and testcancel, so this
Test cannot build for android.
Do we really need a cancellation point, since we don't need to cancel the thread.
Tvrtko's original solution seemed workable, if a bit less polished.

  Tim

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Monday, July 14, 2014 2:28 PM
> To: Tvrtko Ursulin
> Cc: Intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between
> object creation and multi-threaded mm ops
> 
> On Mon, Jul 14, 2014 at 02:13:22PM +0100, Tvrtko Ursulin wrote:
> > On 07/14/2014 02:07 PM, Chris Wilson wrote:
> > >>>You don't have any cancellation points in the loop. (mmap may or
> > >>>may not be, it is not required to be.)
> > >>>
> > >>>But rather than use a global, just pass a pointer to a local struct.
> > >>
> > >>It doesn't need both a cancellation point and a flag. Should I just
> > >>add pthread_testcancel in the loop and not have any flag at all?
> > >
> > >testcancel also neatly avoids the handwavely lack of mb().
> >
> > Barrier for what? But it doesn't matter, I'll re-spin with testcancel.
> 
> It just makes an assumption that the compiler and processor don't skip the
> read. Since it so simple to be pedagolically correct, it seems pointless to leave
> it using volatile.
> 
> > >>>Oh, and igt_assert. But kill the asserts in mm_stress_thread() first.
> > >>
> > >>Why remove completely? My thinking was to use assert vs igt_assert
> > >>to distinguish between assumptions about system behaviour, and
> > >>igt_assert for assertions about tested functionality.
> > >
> > >If the assert fires you make the igt test runner angry. Might as well
> > >report a test failure rather than break down completely.
> >
> > I am not familiar with the test runner, but if it cannot handle a test
> > failing in a way other than it expects it so it deserves to be angry.
> > :) But OK, I'll change it.
> 
> Actualy the SIGABRT will be delivered to the thread so you just get an ugly
> assert and a PASS if you do not propagate the failure...
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx