Designing ServiceStack and ServiceStack.Redis with a message exchange - multithreading

Question

I have reviewed and implemented / tested all the messaging options with ServiceStack that I know of (and I've searched on and off for a long time). The two are Pub/Sub and RedisMQ. Both of these have limitations that I needed to go beyond. I have already done this and have a solution that works perfectly for my system. The purpose of this posting / question is to see if I missed a better way, and a check on if my solution is really thread-safe. So far it is working well and I think it is good.
What I did was create an "exchange" class, and then a "pub" class and a "sub" class. My need was to have an arbitrary number of publishers, in any number of threads, publish to an arbitrary number of subscribers, in any number of threads. The only restriction is that my publisher and my subscriber can not be in the same thread, as this causes deadlock. This is by design, so for me not a limitation, as I want blocking subscribers (this could actually be changed with one line of code, but is not my application need and would actually be a negative). Also note that the subscribers can be to unique publishers or any number of subscribers to the same publisher (fan-out). This was the MQ limitation I needed to resolve. The Pub/Sub limitations were even greater, but let's not digress into why they did not solve my needs.
The usage construct for what I call RedisMEnQ (En = Enqueue because it uses Redis.EnqueueItemOnList) is to instantiate the pub class for each publisher, and a sub class for each subscriber. The pub and sub classes both own an instance of the exchange class, thus sharing the same exchange code. There is no direct interaction between pub and sub classes except through Redis. The exchange code implements locks so that the various threads are thread safe during exchange transactions, and of course the redis connections are unique for each thread and thus thread safe.
The Exchange code is the most interesting, and quite short, so I thought I'd post it:
public class Subscriber
{
public int id { get; set; }
public string key { get; set; }
public bool active { get; set; }
}
public class RedisQueueExchange
{
private IRedisList<Subscriber> RedisSubscribers;
IRedisClient Redis;
public string Key { get; set; }
public const string SubscriberListKey = "exchange:subscribers";
private int id;
public int ID { get { return id; } private set { id = value; } }
private Object thisLock = new Object(); // Mutuall exclusion lock
public RedisQueueExchange(IRedisClient _redis, string _key)
{
Key = _key;
Redis = _redis;
RedisSubscribers = Redis.As<Subscriber>().Lists[SubscriberListKey];
}
private int addSubscriber(string _key){
Subscriber sub = new Subscriber { id = 0, active = true, key = _key };
List<Subscriber> subscribers = RedisSubscribers.GetAll();
int idx = subscribers.FindIndex(x => !x.active);
if (idx < 0)
{
sub.id = idx = subscribers.Count;
RedisSubscribers.Add(sub);
}
else
{
sub.id = idx;
RedisSubscribers[idx] = sub;
}
return idx;
}
private List<Subscriber> findSubscribers(string key)
{
List<Subscriber> subscribers = RedisSubscribers.GetAll();
return subscribers.FindAll(x => x.key.Equals(key));
}
public int Subscribe(){
lock (thisLock)
{
ID = addSubscriber(Key);
return ID;
}
}
public string getSubscribeKey(int id)
{
return "sub:" + id.ToString() + ":" + Key;
}
public void UnSubscribe(int id)
{
lock (thisLock)
{
List<Subscriber> subscribers = RedisSubscribers.GetAll();
int idx = subscribers.FindIndex(x => x.id == id);
RedisSubscribers[idx].active = false;
}
}
public int pubMsg(string msg)
{
lock (thisLock)
{
List<Subscriber> subList = findSubscribers(Key);
int retVal = subList.Count;
foreach (Subscriber sub in subList)
{
string subkey = "sub:" + sub.id.ToString() + ":" + Key;
Redis.EnqueueItemOnList(subkey, msg);
}
return retVal;
}
}
public void clearExchange(){
if(RedisSubscribers != null )
RedisSubscribers.Clear();
}
}
There are lots of ways to approach the problem, but to understand the code one thing should be clarified. I am reusing subscriber ids. That makes it slightly more complex than it would be otherwise. I didn't want to have unnecessary gaps in subscriber ids, so if a subscriber unsubscribes, the next subscriber will pick up the unused id. I put the locks in so that a subscriber does not partly subscribe while a publisher is publishing. Either the subscriber is fully subscribed or not at all.