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
<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 */
Yes, and glibc will warn if you do double free. I still think that it's
reasonable to accept that patch.
Maxim.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
