Question

I have a method like this:

public IOrganizationService GetConnection(bool multi)
        {
            if(!multi)
            {

            Parallel.For(0, 1, i =>
            {
               dynamic _serviceobject= InitializeCRMService();

            });
            }

            else
            {
                ThreadPool.QueueUserWorkItem
                (
                    new WaitCallback
                     (
                         (_) =>
                        {
                            dynamic _serviceobject= InitializeCRMService();

                        }
                     )
                );
            }

        }

I want to return the _serviceobject *directly* from inside the method.Will returing it twice i.e once from if and once from the else loop solve my problem.Please note I am using Multithreading using the concept of Pool threading.Will the _serviceobjects stay unique in case two threads are running parallely.I do not wan’t any interaction to happen between my threads.

Answer 1

The code inside of WaitCallback will execute in the thread pool, and will do so probably after GetConnection has returned (that’s the point of doing asynchronous operations). So, since it is another thread (with another call stack) and it will potentially execute after GetConnection has returned, you cannot make GetConnection return from inside of WaitCallback. If you really want to do that, then you will have to make GetConnection wait until WaitCallback has completed execution. ManualResetEvent can do the trick:

public IOrganizationService GetConnection(bool multi)
{
    var waitHandle = new ManualResetEvent(false);
    dynamic result = null;
    if(!multi)
    {
        Parallel.For(0, 1, i =>
        {
           result = InitializeCRMService();
           waitHandle.Set();
        });
    }
    else
    {
        ThreadPool.QueueUserWorkItem
        (
            new WaitCallback
            (
                (_) =>
                {
                    result = InitializeCRMService();
                    waitHandle.Set();
                }
            )
        );
    }
    //We wait until the job is done...
    waitHandle.WaitOne();
    return result as IOrganizationService; //Or use an adecuate casting
}

But doing this defies the point of having asynchronous operations in the first place. Since the caller thread will have to wait until the job is done in another thread, sitting there, doing nothing… Then, why don’t just do it synchrnously? In a word: Pointless.

The problems is that returning the value directly is a synchronous API. If you want asyncrhonous operations, you will want an asycrhonous API. If you will have an asynchronous API then you are going to have to change the way the caller works.

Solutions include:

1. Having a public property to access the reuslt (option 1)
2. Having a callback (option 2)
3. resourcing to events
4. Returning a Task (or use the async keywork if available)
5. Returning IObservable (using Reactive Extensions if available)

Notes:

1. Having a puplic property means you will need to deal with syncrhonization in the caller.
2. Having a callback, means an odd way to call the method and no explicit way to wait.
3. Using events has the risk of the caller staying subscribed to the event handler.
4. Returning a Task seems like an overkill since you are using the thread pool.
5. Using IObservable without Reactive Extension is prone to error, and much more work compared to the alternatives.

Personally I would go for the callback option:

public void GetConnection(bool multi, Action<IOrganizationService> callback)
{
    if (ReferenceEquals(callback, null))
    {
        throw new ArgumentNullException("callback");
    }
    if(!multi)
    {
        Parallel.For(0, 1, i =>
        {
            callback(InitializeCRMService() as IOrganizationService);
            //Or instead of using "as", use an adecuate casting
        });
    }
    else
    {
        ThreadPool.QueueUserWorkItem
        (
             new WaitCallback
             (
                 (_) =>
                 {
                      callback(InitializeCRMService() as IOrganizationService);
                      //Or instead of using "as", use an adecuate casting
                 }
             )
        );
    }
}

The caller then does something like this:

GetConnection
    (
        false,
        (seriveObject) =>
        {
            /* do something with seriveObject here */
        }
    );
//Remember, even after GetConnection completed seriveObject may not be ready
// That's because it is asyncrhonous: you want to say "hey Bob do this for me"
// and you can go do something else
// after a while Bob comes back an says:
// "that thing you asked me to do? well here is the result".
// We call that a callback, and the point is that you didn't have to wait for Bob
// you just kept doing your stuff...
//So... when is seriveObject ready? I don't know.
//But when seriveObject is ready the callback will run and then you can use it