2011-06-30 17:46:53 +02:00
|
|
|
/* Copyright (c) 2008, 2011, Oracle and/or its affiliates. All rights reserved.
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; version 2 of the License.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
2011-06-30 17:46:53 +02:00
|
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
@file
|
|
|
|
|
|
|
|
Unit tests for lock-free algorithms of mysys
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "thr_template.c"
|
|
|
|
|
|
|
|
#include <lf.h>
|
|
|
|
|
|
|
|
int32 inserts= 0, N;
|
|
|
|
LF_ALLOCATOR lf_allocator;
|
|
|
|
LF_HASH lf_hash;
|
|
|
|
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
int with_my_thread_init=0;
|
|
|
|
|
2009-11-17 19:31:40 -07:00
|
|
|
/*
|
|
|
|
pin allocator - alloc and release an element in a loop
|
|
|
|
*/
|
|
|
|
pthread_handler_t test_lf_pinbox(void *arg)
|
|
|
|
{
|
2011-07-07 08:22:43 -03:00
|
|
|
int m= *(int *)arg;
|
2009-11-17 19:31:40 -07:00
|
|
|
LF_PINS *pins;
|
|
|
|
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_init();
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
pins= lf_pinbox_get_pins(&lf_allocator.pinbox);
|
|
|
|
|
2011-07-07 08:22:43 -03:00
|
|
|
for (; m ; m--)
|
2009-11-17 19:31:40 -07:00
|
|
|
{
|
|
|
|
lf_pinbox_put_pins(pins);
|
|
|
|
pins= lf_pinbox_get_pins(&lf_allocator.pinbox);
|
|
|
|
}
|
|
|
|
lf_pinbox_put_pins(pins);
|
|
|
|
pthread_mutex_lock(&mutex);
|
|
|
|
if (!--running_threads) pthread_cond_signal(&cond);
|
|
|
|
pthread_mutex_unlock(&mutex);
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
|
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_end();
|
|
|
|
|
2009-11-17 19:31:40 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
thread local data area, allocated using lf_alloc.
|
|
|
|
union is required to enforce the minimum required element size (sizeof(ptr))
|
|
|
|
*/
|
|
|
|
typedef union {
|
|
|
|
int32 data;
|
|
|
|
void *not_used;
|
|
|
|
} TLA;
|
|
|
|
|
|
|
|
pthread_handler_t test_lf_alloc(void *arg)
|
|
|
|
{
|
|
|
|
int m= (*(int *)arg)/2;
|
|
|
|
int32 x,y= 0;
|
|
|
|
LF_PINS *pins;
|
|
|
|
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_init();
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
pins= lf_alloc_get_pins(&lf_allocator);
|
|
|
|
|
|
|
|
for (x= ((int)(intptr)(&m)); m ; m--)
|
|
|
|
{
|
|
|
|
TLA *node1, *node2;
|
|
|
|
x= (x*m+0x87654321) & INT_MAX32;
|
|
|
|
node1= (TLA *)lf_alloc_new(pins);
|
|
|
|
node1->data= x;
|
|
|
|
y+= node1->data;
|
|
|
|
node1->data= 0;
|
|
|
|
node2= (TLA *)lf_alloc_new(pins);
|
|
|
|
node2->data= x;
|
|
|
|
y-= node2->data;
|
|
|
|
node2->data= 0;
|
|
|
|
lf_alloc_free(pins, node1);
|
|
|
|
lf_alloc_free(pins, node2);
|
|
|
|
}
|
|
|
|
lf_alloc_put_pins(pins);
|
|
|
|
pthread_mutex_lock(&mutex);
|
|
|
|
bad+= y;
|
|
|
|
|
|
|
|
if (--N == 0)
|
|
|
|
{
|
|
|
|
diag("%d mallocs, %d pins in stack",
|
|
|
|
lf_allocator.mallocs, lf_allocator.pinbox.pins_in_array);
|
|
|
|
#ifdef MY_LF_EXTRA_DEBUG
|
|
|
|
bad|= lf_allocator.mallocs - lf_alloc_pool_count(&lf_allocator);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
if (!--running_threads) pthread_cond_signal(&cond);
|
|
|
|
pthread_mutex_unlock(&mutex);
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
|
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_end();
|
2009-11-17 19:31:40 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-27 23:49:45 +01:00
|
|
|
my_bool do_sum(void *num, void *acc)
|
|
|
|
{
|
|
|
|
*(int *)acc += *(int *)num;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-11-17 19:31:40 -07:00
|
|
|
#define N_TLH 1000
|
|
|
|
pthread_handler_t test_lf_hash(void *arg)
|
|
|
|
{
|
|
|
|
int m= (*(int *)arg)/(2*N_TLH);
|
2014-11-27 23:49:45 +01:00
|
|
|
int32 x,y,z,sum= 0, ins= 0, scans= 0;
|
2009-11-17 19:31:40 -07:00
|
|
|
LF_PINS *pins;
|
|
|
|
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_init();
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
pins= lf_hash_get_pins(&lf_hash);
|
|
|
|
|
|
|
|
for (x= ((int)(intptr)(&m)); m ; m--)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
y= x;
|
|
|
|
for (i= 0; i < N_TLH; i++)
|
|
|
|
{
|
|
|
|
x= (x*(m+i)+0x87654321) & INT_MAX32;
|
|
|
|
z= (x<0) ? -x : x;
|
|
|
|
if (lf_hash_insert(&lf_hash, pins, &z))
|
|
|
|
{
|
|
|
|
sum+= z;
|
|
|
|
ins++;
|
|
|
|
}
|
2014-11-27 23:49:45 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
int unused= 0;
|
|
|
|
lf_hash_iterate(&lf_hash, pins, do_sum, &unused);
|
|
|
|
scans++;
|
|
|
|
}
|
2009-11-17 19:31:40 -07:00
|
|
|
}
|
|
|
|
for (i= 0; i < N_TLH; i++)
|
|
|
|
{
|
|
|
|
y= (y*(m+i)+0x87654321) & INT_MAX32;
|
|
|
|
z= (y<0) ? -y : y;
|
|
|
|
if (lf_hash_delete(&lf_hash, pins, (uchar *)&z, sizeof(z)))
|
|
|
|
sum-= z;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
lf_hash_put_pins(pins);
|
|
|
|
pthread_mutex_lock(&mutex);
|
|
|
|
bad+= sum;
|
|
|
|
inserts+= ins;
|
|
|
|
|
|
|
|
if (--N == 0)
|
|
|
|
{
|
2014-11-27 23:49:45 +01:00
|
|
|
diag("%d mallocs, %d pins in stack, %d hash size, %d inserts, %d scans",
|
2009-11-17 19:31:40 -07:00
|
|
|
lf_hash.alloc.mallocs, lf_hash.alloc.pinbox.pins_in_array,
|
2014-11-27 23:49:45 +01:00
|
|
|
lf_hash.size, inserts, scans);
|
2009-11-17 19:31:40 -07:00
|
|
|
bad|= lf_hash.count;
|
|
|
|
}
|
|
|
|
if (!--running_threads) pthread_cond_signal(&cond);
|
|
|
|
pthread_mutex_unlock(&mutex);
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
if (with_my_thread_init)
|
|
|
|
my_thread_end();
|
2009-11-17 19:31:40 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void do_tests()
|
|
|
|
{
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
plan(7);
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
lf_alloc_init(&lf_allocator, sizeof(TLA), offsetof(TLA, not_used));
|
|
|
|
lf_hash_init(&lf_hash, sizeof(int), LF_HASH_UNIQUE, 0, sizeof(int), 0,
|
|
|
|
&my_charset_bin);
|
|
|
|
|
|
|
|
bad= my_atomic_initialize();
|
|
|
|
ok(!bad, "my_atomic_initialize() returned %d", bad);
|
|
|
|
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
with_my_thread_init= 1;
|
|
|
|
test_concurrently("lf_pinbox (with my_thread_init)", test_lf_pinbox, N= THREADS, CYCLES);
|
|
|
|
test_concurrently("lf_alloc (with my_thread_init)", test_lf_alloc, N= THREADS, CYCLES);
|
2014-11-27 23:49:45 +01:00
|
|
|
test_concurrently("lf_hash (with my_thread_init)", test_lf_hash, N= THREADS, CYCLES);
|
Bug#12552516 LF_HASH REQUIRES MY_THREAD_INIT()
Before this fix, a thread instrumented for the performance schema,
that would perform file io operations, could crash inside the LF_HASH
implementation, in cases when my_thread_init is not called.
The crash itself has not been reported in 5.5 but similar crashes have
been found in 5.6-based development branches, using LF_HASH for
more instrumentation.
The possibility of a crash in 5.5 is confirmed by code analysis.
The problem is that, when my_thread_init() is not called,
which can happen for threads in storage engines or thirs party code,
my_thread_var is NULL.
Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe.
Given that my_thread_var is used:
- only for stacks_ends_here
- only on platform with HAVE_ALLOCA
- only when there is enough room on the stack
and given that the LF_HASH implementation has a fallback
algorythm implemented already when using alloca is not possible,
using my_thread_var->stacks_ends_here is in fact not a strict requirement,
and can be relaxed.
The fix is to:
- test explicitly if my_thread_var is NULL, to account for cases
when my_thread_init() is not used by the calling thread.
- not use alloca in this case, and rely on the fall back code already in place.
so that the LF_HASH can be supported even without my_thread_init().
The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage.
The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
2011-05-13 18:04:49 +02:00
|
|
|
|
|
|
|
with_my_thread_init= 0;
|
|
|
|
test_concurrently("lf_pinbox (without my_thread_init)", test_lf_pinbox, N= THREADS, CYCLES);
|
|
|
|
test_concurrently("lf_alloc (without my_thread_init)", test_lf_alloc, N= THREADS, CYCLES);
|
2014-11-27 23:49:45 +01:00
|
|
|
test_concurrently("lf_hash (without my_thread_init)", test_lf_hash, N= THREADS, CYCLES);
|
2009-11-17 19:31:40 -07:00
|
|
|
|
|
|
|
lf_hash_destroy(&lf_hash);
|
|
|
|
lf_alloc_destroy(&lf_allocator);
|
|
|
|
}
|
|
|
|
|