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 >> <maxim.uva...@linaro.org> 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 */ _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
