Develop Reference

How can you asynchronously call a method containing an infinite loop without blocking?

I've been working on a client application that connects to a server asynchronously using the async and await keywords. I am trying to asynchronously call a method with an infinite loop that checks for an internet connection every few seconds. Here is the initial code for when I start the connection.
private async void button1_Click(object sender, EventArgs e)
{
if (button1.Text == "Connect")
{
button1.Enabled = false;
await ConnectClient();
await Task.Run(() => CheckForInternet());
//Doesn't execute past this line
button1.Enabled = true;
}
...
}
Here is the what my CheckForInternet() method does
private async Task CheckForInternet()
{
while (true)
{ //Close out of the method when done checking
if (stopCheckingForInternet)
return;
//If there is internet
if (InternetGetConnectedState())
{
...
}
//If an internet connection was lost
else
{
...
}
}
}
I want the CheckForInternet() method to have its own individual thread after I call it with the ability to not block, but without the need to use the Thread class. I tried out the method used at
http://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html
In other words, is there a way to start a thread using these methods asynchronously and then after the thread starts, can control be returned back to the context in which it was called?
The asynchronous call blocks and it will not get past it unless it is completely terminated. I want to have the thread stay running indefinitely but also be able to return to the lines below the one where I call this asynchronous method instead of blocking and never allowing the lines below the call to be executed.

You shouldn't use async/await in this scenario. "await" will make your method block. You should use just a Task.StartNew() for your CheckForInternet method (or other suitable way of creating a Task).
Inside CheckForInternet I think it's a good idea to put a "Thread.Sleep()" inside it, to avoid unnecessary CPU consumption.
Creating a Task automatically creates an internal thread.
Async/await makes much for sense if used for unblocking I/O.

You could choose not to await the task returned by Task.Run; that would make your loop independent.
However, I would recommend that you either have a top-level try/catch within CheckForInternet, or save the returned Task and respond appropriately when it completes.

Exiting from timer based polling loop

I have a console app that runs some on demand reporting in a webapplication. The app starts, runs some housecleaning, starts a (1 second) timer, and blocks on a Console.ReadLine(); statement. (I've been meaning to stuff it into a service instead, but that's for another day)
Right now this has no exception-handling, so if the sql server it polls against goes down or there is a network hiccup, it just crashes. I'm trying to implement a crude exception-handling now. Inside the timer-callback I have stuffed the sql-query inside a trycatch. If it fails, it handles the exception by logging, increasing a failurecounter and resuming the timer. If it fails more than 5 times I want it to exit the app (sort of) gracefully. How can I force-quit a console app that is blocked with a readline statement?
Code in a gist: https://gist.github.com/cwattengard/11171563

I think a more elegant solution is to block with a reset event. The timer callback sets this at some point when it considers that it no longer has work to do.
static readonly ManualResetEvent reset = new ManualResetEvent(false);
static void Main(string[] args)
{
var t = new Timer(TimerCallback, null, -1, 1000);
t.Change(0, 1000);
reset.WaitOne(); // the application will sit here until the timer tells it to continue.
}
private static void TimerCallback(object state)
{
try
{
// do stuff.
}
catch (Exception e)
{
failureCounter++;
if (failureCounter > 5)
{
reset.Set(); // release the reset event and the application will exit,
return;
}
}
}

The best way would be to use some sort of signalling mechanism.
For example you start the main thread, do all your initialization (timer etc) then create a non signaled ManualResetEvent and wait on it to fire. If the callback from the timer decides the application should terminate it signals the ManualResetEvent and the main thread is released, completes, and terminates the program...
As a matter of general approach, you should always use signaling and ""cooperative multi-tasking"" within your application. In the sense you signal other threads\ tasks\ actors\ whatever to do stuff, you shouldn't forcefully kill them...

Why thread enters WaitSleepJoin state?

I'm coding singleton class that runs a background thread. Here is how it started and maintained:
private void EnsureBackgroundThread()
{
try
{
if (this.RunnerThread == null)
this.RunnerThread = new Thread(this.BackgroundRunner) { IsBackground = true };
if (this.RunnerThread.ThreadState != ThreadState.Running)
{
Debug.WriteLine("----ApplePushNotificatorService.EnsureBackgroundThread ThreadState: " + this.RunnerThread.ThreadState);
this.RunnerThread.Start();
}
}
catch (Exception ex)
{
this.LoggerService.Log(null, ex);
}
}
I call my method in this class from TestClass like so:
apns.Send("dev", devices, "Testing...", out badIds);
// Wait 5 seconds to let it send stuff through.
Thread.Sleep(5000);
devices.Clear();
devices.Add("some bad id");
// Now let's call this again, but this time we should get back some bad Ids
apns.Send("dev", devices, "Testing...", out badIds);
// Wait 5 seconds to let it send stuff through.
Thread.Sleep(5000);
devices.Clear();
devices.Add("9edc21d0d4e369f50040c5d2c94f2ea29c7d596090e4ddae253712cd406391df");
apns.Send("dev", devices, "Test message for Andrew's phone", out badIds);
// Wait 5 seconds to let it send stuff through.
Thread.Sleep(5000);
I checked error logs and I see exceptions:
Thread is running or terminated; it cannot restart.
In debug it says:
----ApplePushNotificatorService.EnsureBackgroundThread ThreadState: Background, WaitSleepJoin
Why does it enter "WaitSleepJoin" state? Is it because I do "Thread.Sleep" in my test?
Does my code to keep thread alive look correct? How do I work around this? The idea is when "Send" method called on singleton - we need to make sure background thread is running.
EDIT:
This is re-worked code that is working properly
private void EnsureBackgroundThread()
{
try
{
if (this.RunnerThread != null && this.RunnerThread.IsAlive) return;
this.RunnerThread = new Thread(this.BackgroundRunner) { IsBackground = true };
this.RunnerThread.Start();
}
catch (Exception ex)
{
this.LoggerService.Log(null, ex);
}
}

The state tells us that the thread is currently sleeping, likely in one of your calls to Sleep. This means it's still running. Because it's still running, you cannot start it. You're trying to start the same thread multiple times. You can't do that. You start it once, then it's started, and that's that. Trying to start it a second time, either while it's running, or after it is done, is not possible.

Quite simply, as the error states: your thread has been created and is running or terminated - and then you try to start it again.
Presumably in your TestClass you have multiple calls to your singleton class (I'm guessing this may be somewhere under the apns.Send call). The first time you call EnsureBackgroundThread, a single thread will be created and started. The next time you call EnsureBackgroundThread will call Thread.Start on the same thread, thus causing the same error.
It's perhaps important to note here that, when a thread completes, the variable referencing it isn't set to null - but more likely you're just calling the EnsureBackgroundThread method more than once and the code you've written doesn't support that.

TryTake Performance on blockingcollection

I have a programm which sometimes runs significantly slow.
I tried Teleriks Justtrace to find out, what could possible cause a hang of the application.
A non UI thread (therefore I believe it's not really the cause of the hang) does assync. get objects (Enqueues workitems) and deques it to do some work.
Enqueue:
public void EnqueueObject(WorkUnit workunit)
{
try
{
workUnits.Add(workunit);
}
catch (Exception ex)
{
/handle exception
}
}
Dequeue:
public WorkUnit Dequeue()
{
try
{
WorkUnit aWorkUnit = null;
workUnits.TryTake(out aWorkUnit, 1000);
return aWorkUnit ;
}
catch (InvalidOperationException ex)
{
//
}
return null;
}
TryTake was used to check for an abort of current work (instead of the BlockingCollection Complete method which just throws some errors when called - i don't want to use errors for programm flow)
Call to dequeue:
while(!isStopped)
{
ProcessWorkItem(Dequeue());
}
Up to here it looks quite simple.
The problem is, that Teleriks JustTrace shows, that the line "workUnits.TryTake(out aWorkUnit, 1000);" takes 30% of the total execution time of the program.
How can this be?
With more details it shows that inside the TryTake System.Threading.Monitor.Wait takes up all the time - i thought the Wait would send a thread to sleep, so it does not consume something during the wait. Where is the error in the thought?

You can try using workUnits.TryTake(out aWorkUnit) without the timeout parameter. And then, you should modify while loop to look similar to this:
while(!isStopped)
{
WorkUnit wu = Dequeue();
if(wu != null)
ProcessWorkItem(wu);
else
Thread.Sleep(40);
}
Also, if you are running this code on a UI thread it will make your UI unresponsive. You should use for example BackgroundWorker for the operation. Here's the description of BackgroundWorker class from MSDN documentation:
The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.

Locking error in c#

I am trying to do a request-response communication module in c#, using a SerialPort. The
This is a very simple implementation, just to demonstrate that it kinda-works (SerialPort is not working properly (it is a USB virtual COM port), and sometimes eats a few characters, probably some windows driver bug).
However the demo does not work :-/
When Using a propertygrid on the form, which reads out properties of an object, which in turn sends a request to read a property from the remote device, something very strange happens: More than one simulteneous call to SendCommand is made at once.
I tried using a lock{} block to make the calls sequenctial, but it does not work. Even with the lock, more than one call is enters the protected area.
Can you please tell me what am I doing wrong?
My code:
SerialPort sp;
public byte[] SendCommand(byte[] command)
{
//System.Threading.Thread.Sleep(100);
lock (sp)
{
Console.Out.WriteLine("ENTER");
try
{
string base64 = Convert.ToBase64String(command);
string request = String.Format("{0}{1}\r", target_UID, base64);
Console.Out.Write("Sending request... {0}", request);
sp.Write(request);
string response;
do
{
response = sp.ReadLine();
} while (response.Contains("QQ=="));
Console.Out.Write("Response is: {0}", response);
return Convert.FromBase64String(response.Substring(target_UID.Length));
}
catch (Exception e)
{
Console.WriteLine("ERROR!");
throw e;
}
finally
{
Console.Out.WriteLine("EXIT");
}
}
}
The output:
ENTER
Sending request... C02UgAABAA=
Response is: cgAABAAARwAAAA==
EXIT
ENTER
Sending request... C02UgQARwA=
ENTER
Sending request... C02UgAABAA=
Response is: gQARwAAPHhtbD48bWVzc2FnZT5IZWxsbyBYWDIhPC9tZXNzYWdlPjxkZXN0aW5haXRvbj5NaXNpPC9kZXN0aW5hdGlvbj48L3htbD4=
Notice the two ENTER-s, without an EXIT between them? How is that possible?

You need to keep in mind what the lock keyword does, it allows only one thread to enter the lock. Problem is, you are not using any threads. All of this code runs on the UI thread, the main thread of your program.
The next detail you need to know is that the UI thread is special, it is re-entrant. The sp.ReadLine(); call is going to block the UI thread. That is illegal, the UI thread of a GUI program operates as a "single threaded apartment", enabled by the [STAThread] attribute on your program's Main() method. The contract of an STA thread forbids it from blocking, that's very likely to cause deadlock.
To follow the requirements of an STA, the CLR does something special whenever code that runs on the UI thread performs a blocking operation, like SerialPort.ReadLine() does. It pumps a message loop to ensure that messages that Windows sends keep getting dispatched. That message loop does the same thing that Application.Run() does.
Maybe you can see where this is heading, the PropertyGrid is allowed to again call your SendCommand() method. The lock doesn't work at all, this happens on the same thread.
Solving this problem isn't so easy, we can't see the code that gets SendMessage() triggered. But you will need to prevent this from happening, somehow. More background on this behavior in this question.

Where is the field sp assigned? Locks only work on non-null objects.
If sp is assigned differently on each call, then the lock won't be mutually exclusive (locks are only mutually exclusive on the same object instance). In that case, you'd need to have a static field to be used for locking:
private static readonly object _lockObject = new object();
Edit: I see now based on comments in other answers that you are actually running this logic on the UI thread, which is causing the lock to be re-entered multiple times on the same thread (the UI thread) when the message queue is pumped. Run this code on a different thread, and you will gain two advantages: (1) the UI will not lock up as this potentially long-running code executes, and (2) the lock will always be acquired on a new thread, ensuring that subsequent calls to SendCommand will all be on their own thread, and thus enter the lock sequentially as desired.

There are two things you should try/change:
1.Make a separate field, that will be used for locking only
2.Apply the double lock check : double check locking

SerialPort sp;
public byte[] SendCommand(byte[] command)
{
//System.Threading.Thread.Sleep(100);
lock (sp)
{
Console.Out.WriteLine("ENTER");
try
{
string base64 = Convert.ToBase64String(command);
string request = String.Format("{0}{1}\r", target_UID, base64);
Console.Out.Write("Sending request... {0}", request);
sp.Write(request);
string response;
do
{
response = sp.ReadLine();
} while (response.Contains("QQ=="));
Console.Out.Write("Response is: {0}", response);
return Convert.FromBase64String(response.Substring(target_UID.Length));
}
catch (Exception e)
{
Console.WriteLine("ERROR!");
throw e;
}
finally
{
Console.Out.WriteLine("EXIT");
}
}
}