views:

88

answers:

1

We have an external data provider which, in its construtor, takes a callback thread for returning data upon.

There are some issues in the system which I am suspicious are related to threading, however, in theory they cannot be, due to the fact that the callbacks should all be returned on the same thread.

My question is, does code like this require thread synchronisation?

class Foo
    {
      ExternalDataProvider _provider;

      public Foo()
      {
        // This is the c'tor for the xternal data provider, taking a callback loop as param
        _provider = new ExternalDataProvider(UILoop);
        _provider.DataArrived += ExternalProviderCallbackMethod;

      }
      public ExternalProviderCallbackMethod(...)
      {
//...(code omitted)
        var itemArray[] = new String[4] { "item1", "item2", "item3", "item4" };
        for (int i = 0; i < itemArray.Length; i++)
        {
           string s = itemArray[i];
           switch(s)
           {
              case "item1":
                   DoItem1Action();
                   break;
              case "item2":
                   DoItem2Action();
                   break; 
              default:
                   DoDefaultAction();
                   break;              
           }
            //...(code omitted)    
        }
      }
    }

The issue is that, very infrequently, DoItem2Action is executingwhen DoItem1Action should be exectuing.

Is it at all possible threading is at fault here? In theory, as all callbacks are arriving on the same thread, they should be serialized, right? So there should be no need for thread sync here?

+1  A: 

Even if these callbacks weren't on the same thread, they couldn't be the cause of your problem, as your callback method is fully reentrant. There is nothing for you to synchronize.

The problem must be somewhere else, or I'm not understanding your problem correctly :)


PS: in relation to the other threading question you posted, it violates this rule:

  • Must work only on the data provided to it by the caller.

Therefore it is not reentrant. The accepted answer points out why it's not thread safe either.

Thorarin
thanks. this is a simplified version of some very ugly code, but the re-entrancy article is very interesting
miguel
wouldnt this also mean that the first response in my other threading thread would be re-entrant, and therefore thread-safe?http://stackoverflow.com/questions/2779649/thread-local-storage-and-local-method-variables
miguel
also, there is no guarantee that the action methods are re-entrant, right?
miguel
@miguel: No, the Action methods themselves could indeed be causing the problem you're experiencing. But given this code, the right Action method will be executed at the right time. I think you have oversimplified the code you posted.
Thorarin
Thanks again Thorarin, but what about the local-variable example? It only works on the data provided to it by the caller. Also, if all call-backs are delivered on the main GUI thread, calls to the Action methods shuold be inherently serialized as well, right?
miguel
@miguel: They would be serialized, yes. If your component uses COM however, things aren't always as they seem, threadwise.I don't understand your local variable example. Assigning the reference is guaranteed to be atomic, but since the variable is local, what does it matter?
Thorarin