On 23 April 2015 at 16:56, Maxim Uvarov <[email protected]> wrote: > On 04/23/15 13:09, Taras Kondratiuk wrote: >> >> On 04/22/2015 08:54 PM, Maxim Uvarov wrote: >>> >>> On 04/22/15 19:06, Ciprian Barbu wrote: >>>> >>>> On Wed, Apr 22, 2015 at 5:13 PM, Maxim Uvarov >>>> <[email protected]> wrote: >>>>> >>>>> On 04/22/15 15:53, Bill Fischofer wrote: >>>>>> >>>>>> It does that, but as Taras points out there is a race condition. If >>>>>> one >>>>>> thread does an odp_pool_destroy() and it succeeds, another thread >>>>>> could do >>>>>> an odp_pool_create() before the second odp_pool_destroy() and get >>>>>> the same >>>>>> pool handle which would then be deleted by the second >>>>>> odp_pool_destroy() >>>>>> call. >>>>>> >>>>> odp_pool_destroy() should hold lock inside it. (i.e. it already does >>>>> that). >>>> >>>> The scenario is not about a race condition on create/delete, it's >>>> actually even simpler: >>>> >>>> th1: lock -> create_pool -> unlock >>>> th1: lock -> destroy_pool -> unlock >>>> th2: lock -> create_pool -> unlock >>>> th1: lock -> destroy_pool -> unlock >>> >>> Ok, but it's not undefined behavior. If you work with threads you should >>> know what you do. >>> >>> So behavior is: destroy function fails if pool already destroyed. >>> >>> I still think that Mikes test is valid. It's single threaded application >>> with very exact case. >>> Analogy for example: >>> char *a = malloc(10); >>> a[5] = 1; >>> >>> On your logic it has to be undefined behavior due to some other thread >>> can free or malloc with different size. >> >> This in not a valid analogy. Should be something like this. >> >> char *a = malloc(10); >> free(a); >> free(a); /* Here you may free a block which is allocated again by another >> thread */ > > Yes, and glibc will warn if you do double free. I still think that it's > reasonable to accept that patch.
I agree with Taras. pool handle will map to a specific buffer management hardware in the system and the value of odp_pool_t will be the same even if the same pool gets allocated to a different process. Regards, Bala > > Maxim. > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
