Thread safety of ev2citrusleaf_cluster_create() - is it not reentrant?

Client Libraries C Client Library
1

Hello,

I’m investigating a crash in an aerospike app that uses the libevent c client library (2.1.41). I dug into the code to see why a linked list append function crashed on null pointer dereference. I think it’s a race condition, here’s why:

In src/cl_cluster.c, I see that ev2citrusleaf_cluster_create() appends the newly allocated cluster object to a linked list. This linked list appears to have been initialized explicitly to not use locks and therefore is not thread safe. I think it follows that ev2citrusleaf_cluster_create is not safe to call from multiple threads concurrently.

Is this analysis correct? If so, is this non-thread safety intentional? I tried looking all over the code for some documentation about the concurrency contract for this function but couldn’t.

Any insight is appreciated!

2

Correct. Currently the cluster_create() function is not thread-safe. Typically application will do cluster(s) creation once serially at the beginning of the application. The cluster-list is a bit of legacy. In an ideal world, we’d want to remove it and simply have cluster objects around.

While on the subject of threads, please do look at: http://www.aerospike.com/docs/client/libevent/usage/eventbase.html

as well example4. It is important to have self-contained event-base and callback, where the thread which initiates the request will also be the one receiving the callback.

Hope this helps.

3

Thanks for the info. Currently my app does something like this

worker() { c = ev2citrusleaf_cluster_create(); … }

main() { for (i = 0; i < n_threads; i++) { spawn_thread(worker); } }

So each worker thread will call ev2citrusleaf_cluster_create without serializing and is therefore buggy.

That’s what I needed, thanks!