Gotta Be Careful With Static Instance Variables

bug.gif

Today I got nailed by my own laziness - no two ways about it. I had built these pools of data containers - one was for simple time/date-stamped (char *) UDP datagrams, and the other was for std::string * containers. They were both similar in their execution - a single-consumer/single-producer lockless FIFO queue that would act as the pool, and a few methods that would return the next unused one, and recycle one into the pool (or delete it) based on the capacity of the pool.

Simple stuff, really. The problem was that I got a little lazy and made the alloc() and recycle() methods static methods with the actual pool a static ivar of the class. Bad idea.

When I started to use these pools in one of my servers that happened to use about 30 UDP exchange feeds, there was only the one static pool, and it wasn't a single-producer/single-consumer any more. Bad move.

The solution was simple - don't use the static ivar and don't cut corners. I made the pool a class, put the alloc() and recycle() on the class, had the UDP exchange feeds each have a pool, and all was well again. This was pretty easy for the string pool, but took just a little longer for the tagged datagrams. Still, not too bad.

In the end, I solved my nasty data problems because I went back to clean data container streams. Good enough.