My app kept freezing with no reason so I simplified the code until I contained the problem.
Apparently having two synclock (one in a simple sub and another in a timer) caused it. This is the simplified code:
String var1 = "";
String var2 = "";
private void button1_Click(object sender, EventArgs e)
{
Thread thread = new Thread(test_sub);
thread.Start();
}
private void test_sub()
{
lock (var1)
{
Thread.Sleep(1000000);
}
}
private void timer1_Tick(object sender, EventArgs e)
{
lock (var2){}
}
Timer 1 is enabled by default with 1s delay between ticks. As soon as button1 is press, the UI freezes. Can anyone please explain what's causing this weird behavior and what can be done about it? Thanks!
Your problem is not in the Thread, or in the lock per se.
The problem is in the objects used to lock: the two locks are locking on the empty string, which is optimized to use the String.Empty instance.
So your code reads:
private void button1_Click(object sender, EventArgs e)
{
Thread thread = new Thread(test_sub);
thread.Start();
}
private void test_sub()
{
lock (String.Empty)
{
Thread.Sleep(1000000);
}
}
private void timer1_Tick(object sender, EventArgs e)
{
lock (String.Empty){}
}
Which is going to lock the UI thread as soon as timer1_Tick is entered, because the timer (running on the UI thread) is going to lock the same object instance as the test_sub (running on a separate thread).
To ensure two locks are used, you should declare your lock objects like this:
private readonly object _lock1 = new object();
private readonly object _lock2 = new object();
This guarantees no external locking happens on the same objects, and that the two lock objects are distinct instances.
Related
I've looked at some guides and none of them have gotten me all the way there. I've never made a thread, discussed a thread, or seen a thread at the grocery store, so this may be a problem. Currently. I'm trying:
private void btnHUp_MouseDown(object sender, MouseEventArgs e)
{
{
ThreadStart HUp = new ThreadStart(dothis);
t = new Thread(HUp);
t.Start();
}
}
public void dothis()
{
if (intHour < 23)
intHour = intHour += intStep;
lblTimerHour.Text = intHour.ToString("00");
}
private void btnHUp_MouseUp(object sender, MouseEventArgs e)
{
t.Abort();
}
}
That gets me InvalidOperationException was unhandled on the
lblTimerHour.Text = intHour.ToString("00");
line. I read what that means and... it might as well be in Mandarin, I kind of get the general concept-ish of what's going wrong, but it's painfully fuzzy. If you asked me the first step in fixing it I'd look at you like a deer in the headlights. We just haven't gotten that far in my class yet.
The problem here is that the label you are trying to update is owned by the main thread (i.e. what the UI runs on), and that means that only that thread can access/update it. So, since you are in a different thread, you need to tell the UI thread to update the label for you.
Something like this would work:
Action updateLabel = () => lblTimerHour.Text = intHour.ToString("00");
lblTimerHour.BeginInvoke(updateLabel);
What this does is tell the lblTimerHour to invoke the action you define above (updateLabel).
See this post: How to update the GUI from another thread in C#?
lblTimerHour.Invoke((MethodInvoker)delegate {
//Do what you need to do with the label
lblTimerHour.Text = intHour.ToString("00");
});
Edit
This should do the trick:
public void dothis()
{
do
{
if (intHour < 23)
intHour = intHour += intStep;
lblTimerHour.Invoke((MethodInvoker)delegate {
//Update the label from the GUI thread
lblTimerHour.Text = intHour.ToString("00");
});
//Pause 1 sec. Won't freeze the gui since it's in another thread
System.Thread.Sleep(1000);
}while(true); //Thread is killed on mouse up
}
Well, let's take a look and see what you already have.
First, I see you did this.
private void btnHUp_MouseDown(object sender, MouseEventArgs e)
{
ThreadStart HUp = new ThreadStart(dothis);
t = new Thread(HUp);
t.Start();
}
While this certainly is not the freshest stuff around it will still work. If you wanted some fresher ingredients then you might go with this instead.
private void btnHUp_MouseDown(object sender, MouseEventArgs e)
{
Task.Factory.StartNew(dothis);
}
Second, I see this.
public void dothis()
{
if (intHour < 23) intHour = intHour += intStep;
lblTimerHour.Text = intHour.ToString("00");
}
The problem here is that you are attempting to update a UI control from a thread other than the main UI thread. You see UI controls have what is called thread affinity. They can only ever be accessed from the thread that created them. What you have will lead to all kinds of unpredictable problems up to and including tearing a whole in spacetime.
A better option would be to do this.
public void dothis()
{
while (intHour < 23)
{
intHour = intHour += intStep;
lblTimerHour.Invoke((Action)(
() =>
{
lblTimerHour.Text = intHour.ToString("00");
}));
}
}
I assumed that you were missing the loop so I added it. While I cannot say that I personally have a taste for this kind of thing it is much easier to swallow. The real problem here is that the worker thread really does not do a whole lot of useful work. And then to top it off we have to use an awkward marshaling operation to transfer the result back to the UI thread. It is not pretty, but it will work.
And finally that brings me to this.
private void btnHUp_MouseUp(object sender, MouseEventArgs e)
{
t.Abort();
}
You are attempting to abort a thread which is highly inadvisable. The problem is that it yanks control from the thread at unpredictable times. That thread might be in the middle of a write to data structure which would corrupt it. This is actually a pretty bad problem because any data structure in the process of being manipulated from any one of the frames on the call stack could be in an inconsistent state. This includes code you did not write. That is why it is hard to say what you may or may not be corrupting by doing this.
What you need to consider instead is using the cooperative cancellation mechanisms. This includes the use of CancellationTokenSource and CancellationToken. Here is how it might look once we put everything together.
private CancellationTokenSource cts = null;
private void btnHUp_MouseDown(object sender, MouseEventArgs e)
{
cts = new CancellationTokenSource();
Task.Factory.StartNew(() => dothis(cts.Token));
}
private void btnHUp_MouseUp(object sender, MouseEventArgs e)
{
cts.Cancel();
}
public void dothis(CancellationToken token)
{
while (!token.IsCancellationRequested)
{
intHour += intStep;
lblTimerHour.Invoke((Action)(
() =>
{
lblTimerHour.Text = intHour.ToString("00");
}));
Thread.Sleep(1000);
}
}
What this does is signal that the worker thread should gracefully shutdown on its own. This gives the worker thread a chance to tidy things up before eventually terminating itself.
If you want to update the UI every X period of time then there are already existing tools for this; a Timer will do exactly what you want, and it will be much more efficient and easier to code than creating a new thread that just spends most of its time napping. Additionally, aborting threads is a very bad sign to see. Avoid it at all costs.
First create the timer and configure it in the constructor:
private System.Windows.Forms.Timer timer = new System.Windows.Forms.Timer();
private int hour = 0;
private int step = 0;
public Form1()
{
InitializeComponent();
timer.Tick += timer_Tick;
timer.Interval = 1000;
}
Have the Tick event do whatever should be done whenever it ticks.
private void timer_Tick(object sender, EventArgs e)
{
if (hour < 23)
{
hour += step;
lblTimerHour.Text = hour.ToString("00");
}
}
Then just start the timer when you want it to start ticking and stop the timer when you want it to stop:
private void btnHUp_MouseDown(object sender, MouseEventArgs e)
{
timer.Start();
}
private void btnHUp_MouseUp(object sender, MouseEventArgs e)
{
timer.Stop();
}
The timer will automatically ensure that the Tick event handler runs in the UI thread, and it won't block the UI thread (or any other thread) when its waiting for the next event to happen, it will just do nothing.
I want to show an example application of semaphores for a specific problem for my homework.
I added 3 buttons to my C# form and I want to show that only one button at a specific time executes the bank account function in my code. When I click the three buttons in two seconds, the bank account function must run only one time. Because I have a Thread.Sleep(6000) for 6 seconds wait in bank account function. But three of my click runs by 6 second intervals consecutively. How can I change my code to run only one time when I press three buttons consecutively.
The Code is:
namespace semafor_form
{
public partial class Form1 : Form
{
Semaphore semafor=new Semaphore(1,1);
delegate void SetTextCallback(string text);
private void SetText(string text)
{
if (this.textBox2.InvokeRequired)
{
SetTextCallback d = new SetTextCallback(SetText);
this.Invoke(d, new object[] { text });
}
else
{
this.textBox2.Text = text;
}
}
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
}
private void BankAccount()
{
semafor.WaitOne();
double a = Convert.ToDouble (textBox1.Text) + Convert.ToDouble (textBox2.Text);
Thread.Sleep(6000);
semafor.Release();
SetText(a.ToString());
}
private void btnATM_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(BankAccount));
t.Start();
}
private void btnCOUNTER_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(BankAccount));
t.Start();
}
private void btnINT_Click(object sender, EventArgs e)
{
Thread t = new Thread(new ThreadStart(BankAccount));
t.Start();
}
}
}
I may have misread your question. You don't want the buttons to do anything when the thread is being used? (so you'll miss transactions?)
Try this:
private void BankAccount()
{
if (semafor.WaitOne(0))
{
double a = Convert.ToDouble (textBox1.Text) + Convert.ToDouble (textBox2.Text);
Thread.Sleep(6000);
semafor.Release();
SetText(a.ToString());
}
}
Try changing Semaphore semafor=new Semaphore(1,1); to Semaphore semafor=new Semaphore(0,1);
You are initializing a new semaphore without ever releasing it.
This really doesn't sound like an appropriate use of a semaphore. Your problem definition, if I'm reading it correctly, says that the three buttons are mutually exclusive: that pressing any one of them will render all of the buttons inactive for six seconds. You can use a semaphore for this, but a mutex would be more appropriate.
In any event, the problem you're experiencing is that you're waiting on the semaphore, so when the first transaction is done one of the other threads will acquire the semaphore and process. What you want to do is to try to acquire the semaphore. Here's an example.
An example of the latter:
private void BankAccount()
{
if (semafor.WaitOne(0)) // tries to acquire the semaphore
{
double a = Convert.ToDouble (textBox1.Text) + Convert.ToDouble (textBox2.Text);
Thread.Sleep(6000);
semafor.Release();
SetText(a.ToString());
}
}
The WaitOne(0) says, "Try to acquire the semaphore. If it's not immediately available, then return false. If it is available, acquire it and return true."
You could also do this in the button handler. That is, have the button handler acquire the semaphore (using WaitOne(0)), and have it exit without starting the thread if it can't acquire the semaphore. If it does acquire the semaphore, start the thread and have the thread proc release the semaphore when done.
when I click button1 should print A s but when I click button2 need to stop thread1 and need to start thread2, what is the wrong in here please help me
private void button1_Click(object sender, EventArgs e)
{
if (thread2.IsAlive)
{
thread2.Suspend();
}
thread1 = new Thread(threadOne);
thread1.Start();
}
private void button2_Click(object sender, EventArgs e)
{
if (thread1.IsAlive)
{
thread1.Suspend();
}
thread2 = new Thread(threadTwo);
thread2.Start();
}
private void threadOne() {
for (int i=0; i < 20; i++ )
{
Console.Write("A");
Thread.Sleep(500);
}
}
private void threadTwo()
{
for (int i = 0; i < 20; i++)
{
Console.Write("B");
Thread.Sleep(500);
}
}
There's quite a lot wrong, as the other posters have correctly pointed out. I would add this:
1) Most threads in commercial-grade software never terminate during the lifetime of the application - they are written as infinite loops with blocking calls that wait for some sort of signaling from other threads or I/O operations.
2) Continual create/terminate/destroy of thread objects is expensive, difficult to control, awkward-to-debug, unreliable and generally causes pain.
3) If your multithread code contains any of the following:
Suspend()
Resume(), (except in some thread ctors)
Join()
Abort()
IsAlive()
You should probably think again :)
I know you're only learning, but sometimes it's better to patch up holes before they get any bigger :)
You are creating instance of Thread's in the Button Click events, so the if statement that checks threadX.IsAlive will throw error reporting null reference exception
So please create the instance of thread1 & 2 on load
Check for null also.
Use Abort() method instead of Suspend() as you are anyway creating a new thread each time.
private void button1_Click(object sender, EventArgs e)
{
if (thread2!=null && thread2.IsAlive)
{
thread2.Abort();
}
thread1 = new Thread(threadOne);
thread1.Start();
}
private void button2_Click(object sender, EventArgs e)
{
if (thread1!=null && thread1.IsAlive)
{
thread1.Abort();
}
thread2 = new Thread(threadTwo);
thread2.Start();
}
I have a console application that utilizes the BackgroundWorker object and wanted to test my output with a Console.WriteLine(fooBar). However, that application exits as the application executes the Console.WriteLine command.
Here's a watered down version that illustrates what I wanted to do:
protected static void bWorker_DoWork(object sender, DoWorkEventArgs e)
{
for (int i = startId; i <= endId; i++)
{
Console.WriteLine(i.ToString());
Thread.Sleep(1000);
}
}
Any ideas why the application would appear to exit like that?
The application exits because it in fact completes execution and has no more work to do ;-) Once you schedule the background worker and kick off the thread to do it's thing, you have to tell the main thread to stop and wait for one thing or another. A very common way of doing this (Generally used in test/sample code) is to simply issue a Console.ReadKey(); as the very last line of code in your main method. This will cause your application to wait until you press a key before exiting the process.
For your backgroundworker set WorkerReportsProgress to true. Subscribe to ProgressChanged event like this:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
for (var i = 0; i < 1000; i++)
{
backgroundWorker1.ReportProgress(i);
}
}
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
Console.WriteLine(e.ProgressPercentage);
}
If you need to transfer more than just int from your background thread to UI thread, then you could do something like this:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
for (var i = 0; i < 1000; i++)
{
var myObjectInstance = new MyObject{ ...};
backgroundWorker1.ReportProgress(null, myObjectInstance);
}
}
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
var myObjectInstance = (MyObject)e.UserState;
Console.WriteLine(myObjectInstance);
}
I might not be understanding your setup correctly. I'm guessing that you're running the background thread, but the main process is exiting which causes the thread to be stopped before it gets to do anything. Maybe try putting something in your main process that prevents the main thread from exiting like Console.ReadKey();
In this code, when button1 is clicked twice, it creates 2 separate threads. On one click, it creates a new thread on the heap and field t1 points to the new thread on the heap. When I click button2, it aborts the last thread (which t1 refers to).
How do I abort the other thread?
Thread t1;
ThreadStart ts1;
private void button1_Click(object sender, EventArgs e)
{
ts1 = new ThreadStart(myfunc);
t1 = new Thread(ts1);
t1.Start();
}
private void button2_Click(object sender, EventArgs e)
{
t1.Abort();
}
Well, the OO answer would be to hold a list of threads as a field.
private readonly List<Thread> threads = new List<Thread>();
And to then add the newly constructed thread to the list in the first handler.
var thread = new Thread(myfunc);
thread.Start();
threads.Add(thread);
Then you could iterate through each thread in the second handler, aborting each of them in turn.
foreach(var thread in threads)
thread.Abort();
But I think the most important point here is that there is almost never a good reason to call Thread.Abort.
From the MSDN page:
When a thread calls Abort on itself,
the effect is similar to throwing an
exception; the ThreadAbortException
happens immediately, and the result is
predictable. However, if one thread
calls Abort on another thread, the
abort interrupts whatever code is
running. There is also a chance that a
static constructor could be aborted.
In rare cases, this might prevent
instances of that class from being
created in that application domain. In
the .NET Framework versions 1.0 and
1.1, there is a chance the thread could abort while a finally block is
running, in which case the finally
block is aborted.
The thread that calls Abort might
block if the thread that is being
aborted is in a protected region of
code, such as a catch block, finally
block, or constrained execution
region. If the thread that calls Abort
holds a lock that the aborted thread
requires, a deadlock can occur.
You would be much better off using some form of signalling, such as setting a ManualResetEvent that each thread will poll at perioidic intervals. Alternatively, you could use the BackgroundWorker class that has some support for task-cancellation (call CancelAsync on it, and get the worker threads to test CancellationPending periodically). If you are on .NET 4.0, you can also use the TPL.
I would recommend you to take a look at the built in synchronization primitives such as ManualResetEvent and WaitHandle. You can ask a thread if it's running or not by trying to join the thread with Thread.Join. Aborting a thread should only be done as a last resort if the thread is unresponsive.
Here is an modified example of your code that shows how you can prevent the thread from be restarted before it's been stopped properly.
public partial class MainForm : Form
{
private Thread t1;
private ThreadStart ts1;
private ManualResetEvent t1resetEvent;
public MainForm()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
// Got a thread?
if (t1 != null) {
if (!t1.Join(0)) {
// The thread seems to be running.
// You have to stop the thread first.
return;
}
}
t1resetEvent = new ManualResetEvent(false);
ts1 = new ThreadStart(MyFunc);
t1 = new Thread(ts1);
t1.Start();
}
private void button2_Click(object sender, EventArgs e)
{
// Got a thread?
if (t1 != null)
{
// Set the reset event so the thread
// knows it's time to stop.
t1resetEvent.Set();
// Give the thread four seconds to stop.
if (!t1.Join(4000)) {
// It did not stop, so abort it.
t1.Abort();
}
}
}
private void MyFunc()
{
// Long running operation...
while (true)
{
// Do someone want us to exit?
if (t1resetEvent.WaitOne(0)) {
return;
}
}
}
}
The others have given the long versions of the answer, however the obvious simple solution is to simply skip recreating the thread object:
public partial class Form1 : Form
{
Thread thread1;
ThreadStart threadStart1;
public Form1()
{
InitializeComponent();
threadStart1 = new ThreadStart(threadTarget);
thread1 = new Thread(threadStart1);
thread1.Name = "Button1 thread";
}
private void button1_Click(object sender, EventArgs e)
{
thread1.Start();
}
private void button2_Click(object sender, EventArgs e)
{
thread1.Abort();
}
private void threadTarget()
{
Console.WriteLine(Thread.CurrentThread.Name);
for (int i = 0; i < 100; i++)
{
Console.WriteLine(i);
Thread.Sleep(500);
}
}
}
However, I would consider reading up on Threading in .NET using one these guides (I'd recommend Joseph Albahari's guide on aborting - the author of C# in a nutshell) rather than use this method, particularly if you're performing IO or database operations which can leave the objects in unexpected states.
Also, have in mind that calling Abort on a Thread is evil. You should stop the thread with a boolean condition or something like that.
Check this:
http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation