-2

I have the following scenario:

A thread pool of 3 threads, and each one of them should pick from a list of 9 operations randomly. Between that nine operations there are two which can't be performed at the same time, so I'm using a lock in those 2 methods (operations) like below:

private Object lockThis6 = new Object();
private Object lockThis7 = new Object();

public void OpSix(uSupervisor supervisor)
    {
        lock (lockThis6)
        {
            try
            {
                //Intructions
                //Event Handler
                OnOpFinished(supervisor); 
            }
            catch 
            {

            }
        } 
    }

    public void OpSeven(uSupervisor supervisor)
    {
        lock (lockThis7)
        {
            try
            {
                //Intructions
                //Event Handler
                OnOpFinished(supervisor);
            }
            catch 
            {

            }
        }
    }

    //EventHandler
    protected virtual void OnOpFinished(uSupervisor supervisor)
    {
        if (OpFinished != null)
            OpFinished(this, new EventLoad(supervisor));
    }

In the end of the Instruction, an event is raised to "Inform" the thread to pick an operation randomly. Misteriously sometimes the Threads are getting stuck in the lock statement, I was trying to figure it out if it's a dead lock scenario but It's not the case

Tiago Neto
  • 379
  • 1
  • 3
  • 15
  • are these the only locks you have? – Domysee Sep 29 '15 at 12:49
  • 7
    Can you prepare [mcve](http://stackoverflow.com/help/mcve)? Current code is too short to be incorrect as it is. Moreover while preparing mcve you may find a reason of the problem yourself. – Sinatr Sep 29 '15 at 12:50
  • Are you using await inside your lock statements? http://stackoverflow.com/questions/7612602/why-cant-i-use-the-await-operator-within-the-body-of-a-lock-statement – rmn36 Sep 29 '15 at 12:51
  • @Dominik yes, those are the only lock I do have in my code. – Tiago Neto Sep 29 '15 at 12:51
  • @rmn36 no, the instructions inside, are basic operations – Tiago Neto Sep 29 '15 at 12:52
  • @Sinatr In the end of the instruction there is an event to be raised which will "inform" the Thread that another operation can be picked. Is there any chance that the Lock doesn't understand that the operation is over and block all other operations? – Tiago Neto Sep 29 '15 at 12:55
  • 3
    Make lock object static and readonly. – Botonomous Sep 29 '15 at 12:56
  • Show us more code (that event and that "inform" part). Event handlers may block operation if it somehow require same lock. A quick fix is to rise event asynchronously, but then you clearly have design issue. – Sinatr Sep 29 '15 at 12:59
  • How are you picking these random operations? Is there a chance you are picking the same one twice? – Ron Beyer Sep 29 '15 at 13:06
  • @RonBeyer yes there are chances of two different threads have the same operation picked. If it is operation Six or Seven only one thread can perform it at the time – Tiago Neto Sep 29 '15 at 13:09
  • @Sinatr please check my updates on the post – Tiago Neto Sep 29 '15 at 13:12
  • 2
    Still not enough code. You simply rising event inside `lock`, try to move it outside. If you need further help please post how this event is used (subscribers and their code). – Sinatr Sep 29 '15 at 13:15
  • @CaptainAnon What makes you think that the lock object should be static? There's no indication that there's static field being accessed in that critical section. – Servy Sep 29 '15 at 13:16
  • @code4life "static" fields are not shared among app domains. Yet still I could be that the lock needs to be static nevertheless. The problem is, that the information question makes it very hard to reason about that and it might be totally wrong. – Christian.K Sep 29 '15 at 13:26
  • @Sinatr the simple fact of moving the Event Handler outside the Lock solved the problem. The problem was the fact that as the Event Handler was inside the Lock was always turned On. Solved – Tiago Neto Sep 29 '15 at 13:30
  • @Christian.K: sorry, my bad. Static would make sense for odd situations though. For instance a 3rd party library using its own DI and the app using a different DI. – code4life Sep 29 '15 at 13:31
  • @TiagoNeto: what does the debugger show you? Go into the Threads view and see what's going on. If you can't make sense of it, take a screenshot of the threads view and post it on your question, we'll see if we can help you out. – code4life Sep 29 '15 at 13:33

1 Answers1

-1

The problem in my code is in the Event Handler. Due to the fact that the Event Handler is called inside the Lock statement, the Lock will always be locked for any other Thread that pick that operation.

By simply move the Event Handler outside the Lock Statement solve my problem.

Tiago Neto
  • 379
  • 1
  • 3
  • 15
  • This does not make any sense. Your code is clearly incomplete. You must have some re-entrant lock in your EventHandler but aren't showing it. – Aron Sep 29 '15 at 17:55