Strategy for ensuring an Object (List) is accessed within an area, but can be referenced external

Question

I am looking at creating a ServiceManager area (set of classes with a facade interface) where other areas can sign up to and offer "services" via, and pass on requests. I plan on running this class in its own thread, and I want to keep critical regions at a minimum and handled purely within this area.

When an area sign up they get their own inbox and outbox of commands, which is a List of ServiceRequests.

Now my dilemma is, if I do not share the link to the outbox (the service providers area) I will need to locate the box via a search for a match (critical region across all signing up, and due to this all submitting requests as well, defeating the purpose of a local outbox).

Alternative I give a link outside of the ServiceManager area, then a new external area is coded it is possible to skip the critical region and directly update the list, bypassing this.

---

My solution is to within the code of the ServiceManager area to create a "key" object where direct access never leave the area (any object including a complete empty will work).

When an area is signed up, they are getting a class in return, where a link to the above object along with a link to the where the ServiceManager object of the signed up area. (which contains direct inbox/outbox link along with other information).

This "token" object also contains following code

public ServiceObject GetServiceObject(Key key)
{
    If (key == this.key)
    {
        return serviceObject;
    }
    return null
{

this way even if the command is public its contents can only be accessed within the ServiceManager area as its the only area with direct access to the Key object. This bypass above two concerns of having a shared critical region across all service users, and the risk of those service users accessing their lists directly.

So it solves the problem but to me this looks real ugly, is there a smarter approach, and if how?

Answer 1

Use the classes in System.Collections.Concurrent - they have efficient locking implementations and also provide producer/consumer behavior along with partitioning for distributing work loads.

With these classes you will be able to model any scenario, whether you have many readers, many writers, or both at once. All without having to write any locking code of your own.

Update: example code wrapping a queue to provide a facade for an optional future split of the command queue into multiple queues.

Let's assume that your concern about the number of threads inserting commands into the queue has some merit. You can cover yourself by creating a thin wrapper around the underlying queue, which allows you to pass out different wrapper instances if you in the future discover that this is necessary.

public interface ICommandQueue {
     void Add( Command command );
}

public class CommandQueue : ICommandQueue {
     private ConcurrentQueue<Command> queue = new ConcurrentQueue<Command>();

     public void Add( Command command ) {
         queue.Enqueue( command );
     }
}

When you instantiate a ServiceObject, make sure that you pass in an ICommandQueue instance on the constructor (either manually or using an IoC container), or use a static CommandQueueFactory to have the SO obtain it on-demand if that works better for you.

public class ServiceObject {
     private ICommandQueue queue;

     public ServiceObject( ICommandQueue queue ) {
         this.queue = queue;
     }
}

This will let you change the number of queues later, rather than writing all of the (potentially unnecessary) code now. Never solve a problem that you are not sure that you have :-)

More information:

• MSDN: Thread-Safe Collections
• MSDN: Concurrent Collections in .NET 4
• MSDN: System.Collections.Concurrent

Answer 2

The code I am currently using is this.

//base class of no use on its own. Used to lock the AreaIdentifier
public class Key
{
    public Key()
    {
    }
}

//public direct link to ServiceArea info, without ability to access it without the internal key
public class AreaIdentifier
{
    Key key;
    ServiceArea serviceArea;
    public AreaIdentifier(ServiceArea serviceArea, Key key)
    {
        this.key = key;
        this.serviceArea = serviceArea;
    }

    public ServiceArea GetServiceArea(Key key)
    {
        if (this.key == key) return serviceArea;
        return null;
    }
}

}

The reason for this approach is that external areas must be coded in a way that the "inner code" of the "transport layer" and the adding and removing does not mess up the actions. Now if I share a direct link

So when outer area (in its own thread) wants to add a new command it does it by calling following call which is placed within the Communication Layers code. (there is a private Key variable within this area, that is not accessable via the AreaIdentifier (but known) nor shared in other ways outside the area.

    //Put a command in the outBox for pickup by CommunicationLayer
    public Boolean AddCommand(AreaIdentifier area, CommandRequest command)
    {
         //attempt enter critical region or return false;             
         ServiceArea temparea = area.GetServiceArea(key);
         List<Command> tempOutbox = temparea.GetOutBox();
         tempOutbox.Add(command);
         //exit critical region
         return true;
    }

The only downside I see from this approach is that I have the public function of "GetServiceArea" which kinda makes little sense outside the "internal" functions of the TransportLayer