Question

We are working on integrating two different applications that run simultaneously and share data. One application provides the data, the other one computes some values based off external systems and the data and has to provide it back to the first application.

We are using this library to share the data between the applications: http://grouplab.cpsc.ucalgary.ca/cookbook/index.php/Toolkits/Networking

The library basically allows to create a shared dictionary which can be queried by any application (as long as it knows the location of the shared dictionary).

So, what should happen is program A has to provide some data to program B and program B uses this data and returns some other data back to program A.

My problem is how do I make the program A wait for the response from B. In more concrete terms, I can put an object in the shared dictionary, the other program gets notified of a change in the dictionary, it can compute some attribtues and update the object in the dictionary. Program A can get notified, but I want program A to wait till it gets back this response – program A’s action should be based on the returned value.

A very ugly way I see this can be done is have an infinite loop inside the function, that keeps querying the dictionary to see if the object has been udpated – if it has break out of the loop and use the object and its computed attributes. Does anyone know of a nicer solution?

Answer 1

Using their subscription model, you are able to avoid all infinite-looping. Why would you need to loop when the only times you need to check is when something is actually updated? Since you subscribe to key patterns in the dictionary and your connection will be notified when a key fitting that pattern is updated/added, you only need to check on that.

So basically, you can use a ManualResetEvent to wait for synchronization within your own system. Here is an example of usage of ManualResetEvent:

using System;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        //    create the reset event -- initially unsignalled
        var resetEvent = new ManualResetEvent(false);
        //    information will be filled by another thread
        string information = null;

        //    the other thread to run
        Action infoGet = delegate
        {
            //    get the information
            information = Console.ReadLine();
            //    signal the event because we're done
            resetEvent.Set();
        };

        //    call the action in a seperate thread
        infoGet.BeginInvoke(null, null);
        //    wait for completion
        resetEvent.WaitOne();
        //    write out the information
        Console.WriteLine(information);
    }
}

To translate to your framework, you might have the subscription handler check what was updated, find that wait handle and signal it, thus advancing the proper waiting threads.