Hiredis replies in a multithreaded application

[Luveh Keraph]

I have a multithreaded Linux C application that interacts with a Redis database by means of the Hiredis library, the synchronous API.  It works as expected, but I have noticed that every once in a while, a response from the redisCommand() function seems to be overwritten by another thread. The multithreaded character of the application is no doubt behind it: when I use four or eight instances of the relevant thread, I have yet to notice the issue. With sixteen threads, I see one such overwriting event every five hours or so during the life of my application; with thirty two threads, several events are apt to show up every hour.

Before I start adding mutex locks - which, if carried to extremes, just end up serializing the application - I would like to ask members of this forum for advice on how to proceed. I was thinking that copying the contents of the redisCommand() reply locally, and then operating on the copied data, might help. However, I am not sure how efficient that will be in general - the redisCommand() reply, which essentially amounts to a linked list, might contain numerous entries.  At any rate, if anybody with extensive experience with Hiredis (either the synchronous or the asynchronous API) could give some pointers on how to deal with this, I would be most interested to read what they have to say.

[sewe...@gmail.com]

redisContext is NOT thread-safe. You need to have mutex to protect it in a multiple-threading environment.

In order to avoid serializing your application, you can create a connection pool, i.e. a pool of multiple redisContext objects. Each thread fetches a redisContext from the pool with locking, does the command call, and finally releases redisContext back to the pool with locking. Check connection_pool.h and connection_pool.cpp for an example.

Regards

[Luveh Keraph]

Thanks. Actually I think that my question was misleading - looking into the code in more detail, I am now convinced that the problem that I have is not what I described. My apologies. But, your comment is relevant and noted.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/f2999307-c131-4b38-a8ce-4bcf7d4a5ac0n%40googlegroups.com.