This question already has answers here:
What is the difference between ManualResetEvent and AutoResetEvent in .NET?
(11 answers)
Closed 9 years ago.
I read about event, which allow me to wait for other thread: AutoResetEvent and ManualResetEvent.
What are the differences between these two classes? Which class is better for a highly concurrent program?
The difference is in what happens when the event is signaled (set).
the manual-reset event will stay signaled until your explicitly reset it again
the auto-reset event will automatically get reset (unsignaled) once the first thread waiting for it gets awaken
In general I find it easier to work with manual reset events because in most cases it is a bit more straight-forward to determine the state of the event at any given time.
That said there are cases when the behavior of the auto-reset event lends itself better to achieving synchronization because you are guaranteed that only one of the waiting threads will be signaled. So if you have a producer/multiple-consumers scenario where any, but only, one consumer should be signaled you should consider the auto-reset event.
Related
This question already has answers here:
When would you ever use nested locking?
(3 answers)
Closed 11 months ago.
It says here :
While a lock is held, the thread that holds the lock can again acquire and release the lock.
Question. For what purpose can several consecutive locks be used in one thread? Or does it give nothing, but the article says to clarify that inside one thread the code in the second lock will also be executed because the lock is used in the same thread?
I just want to understand the purpose of this information.
Its called recursive locking. It is useful if you have complex paths that may end up trying to lock a resource twice (like in a recursive function). It saves you have to keep track of whether or not you already have a lock.
It is typically implemented as a counter, after the first lock subsequent locks just increment the counter, unlocks decrement, when the count reaches 0 the mutex is released
This question already has answers here:
Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on
(22 answers)
Closed 2 years ago.
I'm a beginner with C# so maybe I don't really understand why I have this error.
System.InvalidOperationException: Cross-thread operation not valid:
Control 'lstb_files_r' accessed from a thread other than the thread it
was created on.
This is what I'm doing:
I drop X csv.
I read the first one (lstb_files_r.SelectedIndex = i;)
after finishing I would like to read the 2nd (i++). But I have this error...
Can someone explain to me how can I solve that please ?
When I asked my question I continued to look all the links and I've found something (maybe it's not the best way but I will find an other solution)
I use delegate
lstb_files_r.Invoke((MethodInvoker)delegate
I put all the code inside and it works.
You are performing the cross threaded opertaion which means you are in one thread (which is your algorithm) and want to perform something in another thread (here GUI is another thread) which is not allowed. For that you have to call GUI thread and perform the function. In C# the easiest way is to use backgraoudworker Use of backgroudworker can see here how to use background worker.
In backgroundworker use progressreport to perform the GUI operations. If you need further help I can help you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Do we really have to do this?
// Loop until worker thread activates.
while (!workerThread.IsAlive);
Wouldn't it be better to just use a ManualResetEvent (or else) at the start of the thread's function?
Edit 1:
Perhaps in the MSDN example context it would be "appropiate":
// Start the worker thread.
workerThread.Start();
Console.WriteLine("main thread: Starting worker thread...");
// Loop until worker thread activates.
while (!workerThread.IsAlive);
Otherwise this just feels like an awful code smell.
Source: http://msdn.microsoft.com/en-US/library/7a2f3ay4(v=vs.80).aspx
Please ignore the MSDN example, it's horrible and senseless. In particular, the spin waiting on IsAlive makes no sense because there is no way for the thread to be terminated "before it has a chance to execute", as the MSDN says. The thread is free not to check the flag you set for requesting termination until it is ready. Spin-waiting on IsAlive never makes sense -- use Thread.Join() to wait on exit, and events (or monitors) to wait for other states.
Good practice is to use the Task-based Asynchronous Pattern (TAP)
Use Task.Run like this,
public async Task DoStuff(CancellationToken token)
{
await Task.Run(
() => Console.WriteLine("Stuff"),
token)
}
or just,
Task.Run(() => Console.WriteLine("Stuff")).Wait();
There is no built-in infrastructure to wait for thread to start, because in most cases this should not be important. We must wait for thread to finish always, but let it do about its business in the mean time.
You probably even don't want to wait for thread to start. You probably want for thread to activate some of its functionality, and in general case there could me more than one of those functionalities. No built-in system can cater for this, so you have to roll your own synchronization.
Just have some event that is created when the thread is created, but is raised in the thread run code. When you create and start the thread wait on this event and that's it.
This question already has answers here:
Can .NET Task instances go out of scope during run?
(2 answers)
Closed 8 years ago.
Lets assume I run such a code
Task.Factory.StartNew(...).ContinueWith(...);
I don't store reference for neither of two created tasks so can I be sure that they won't be disposed before starting or at the process of executing? If yes then where do reference to these tasks are being held?
A reference to a TPL Task is held by the system under two conditions:
The Task is scheduled
The Task is running
Upon completion of the Task and any child tasks, the reference is thrown away. References in your code will behave as expected.
I believe you have some confusion regarding garbage collection and Dispose. This question may enlighten you.
Difference between destructor, dispose and finalize method
Destructor implicitly calls the Finalize method, they are technically same. Dispose is available with those object which
implements IDisposable interface...
Should you dispose Tasks?
Stephen Toub says:
No. Don’t bother disposing of your tasks.
https://devblogs.microsoft.com/pfxteam/do-i-need-to-dispose-of-tasks/
This question already has answers here:
Background timer to update UI?
(4 answers)
Closed 9 years ago.
I need to count down time and the ticks must be in synch with time.
First I tried DispatcherTimer. It interacts fine with UI but it lags.I found a lag of almost 5 seconds after two minutes count down.
Then I switched to System.Timers.Timer.This one seems to be more in synch with real time but if I fire events from it which are caught by UI thread I am getting errors.Also inside Timer Elapsed event handler I can't interact with UI elements either.Being WPF amateur my question is how to use it with UI thread to avoid this sort of anomalies?
You can use Dispatcher.BeginInvoke() method. It will schedule delegate to UI thread. Dispatcher is a property of every control.
control.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new Action(() => { ... } ));