How to wait(to test) perform the function (Monitor.Enter While vs(var))?

Hi all, I have in writing WCF service, there was a following problem: there are метод1, which may execute for a long time, it can be called from any instance, but must work this method could be only one. This part I decided to through isBusy=true in the beginning and isBusy=false at the end. This part works.

Self-hosted console application periodically calls some methods must not be run simultaneously with методом1. Ie if метод1 running, then wait until it finishes and then run those methods. And then I thought, what better use is there any difference, or to wait until isBusy=true. Or you can create busyLock.

Below is an example test application that does what I need using two different methods.

static bool isBusy = true;
 static object busyLock = new object();

 static void Main(string[] args)
 new Task(longTaks1).Start();
 while (isBusy) { }

 new Task(longTaks2).Start();


 static void taskMustRunOnlyWhenLongTaskNotRunning()

 static void longTaks1()
 isBusy = true;
 isBusy = false;

 static void longTaks2()

Rather, the question is whether there is a significant difference in approach and what are the pitfalls. Thanks for the replies.

P. S isBusy on the service I keep in the box potatomaster singleton.
July 9th 19 at 13:09
3 answers
July 9th 19 at 13:11
Use for this Event. Threw an alarm condition, the service is busy.
For your problem better ManualResetEvent. The service completed the task and set an alarm condition.
In other threads will just write
event.WaitOne(<number of milliseconds>);
If there is no signal condition, your thread will sleep for the desired time and wakes up when the service completes and installs the signaled state or the timeout.
thank you, apparently this is what you need, go to read how to implement it correctly - chelsie.Walker commented on July 9th 19 at 13:14
July 9th 19 at 13:13
1.If you don't use lock, but write Enter exit, the implementation is wrong and not safe, Google the try finally taken.
2. The While loop will busy the CPU (almost always)
I advise you to read something that, judging by the question , in this thread You are a beginner.
All the above written obstragirovanno tasks and wcf.
3. Busy use is not correct in Your code.
thanks for the reply, that actually asked to be instructed as is usually correctly done, and already read in this direction - chelsie.Walker commented on July 9th 19 at 13:16
the night did not notice that my example with do while is not working, now started it and noticed 100% time of one CPU. That is all not related to wcf I understand, it's just easier to explain by example. - chelsie.Walker commented on July 9th 19 at 13:19
All right. Just read multithreaded programming. Check bizy with this implementation is still not reliable in principle. - chelsie.Walker commented on July 9th 19 at 13:22
July 9th 19 at 13:15
not using lock?
lock I didn't use as we don't want to create additional nesting (just IMHO), but the subject matter that's not change, lock is the same as monitor.enter\exit. - chelsie.Walker commented on July 9th 19 at 13:18

Find more questions by tags Asynchronous programmingWCFC#