Develop Reference

My thread disappears from thread list after some time

I have multi thread program with C# language.
When load main form, 4 thread start that all of them work with while(true)
Every thread run, active and exist in thread list but after 30 ms, one of thread (without any error) disappear from thread list and doesn't work
even breakpoint not work.
I want read data from TCP and process 3 steps then save to database
Task1: have while(true) and read data from tcp and add to blockingcollection bk1
Task 2: in while(true), take data from bk1 and process data then add data to BlockingCollection bk2
Task3 in while(true) take data from bk2 and process then bk3
Task 4 in while (true) take data from bk3 then insert database
I define task:
Task.Factory.StartNew(() => myfunction, CancellationToken.None,
TaskCreationOptions.PreferFairness, TaskScheduler.Default);
When click button1 all of tasks start and work correctly after some time task3 change status to RanToCompletion and does not work I didn't use async and await in code because task works parallel and don't need wait for other task.
Even TaskCreationOptions set to LongRunning
My function have while(true) and work producer-consumer method.
Please help me about problem.
Thanks for attention.

Your code never awaits that task to end. Use await and Task.Run instead:
await Task.Run(()=>myFunction());
or
await Task.Run(myFunction);
Tasks aren't threads. They're a job that gets executed by a threadpoool thread. Creating a thread is an expensive operation. To avoid the cost of creating and destroying threads, .NET keeps a pool of worker threads. Jobs, in the form of Action or Func delegates, get posted to that ThreadPool and executed by one of the worker threads.
Task.Run or Task.Factor.StartNew post a job to the threadpool for execution and return a Task, essentially a "promise" object. This means the calling thread isn't blocked waiting for the task to complete and can do other work. await makes it easy to await for that task to complete and get back to the calling thread. Once the task completes, execution can resume with the code after await.
In a desktop application that means the UI thread doesn't get blocked waiting for a task to complete and can keep processing Windows messages, button clicks, refresh its windows etc. When the task completes, execution will resume on the UI thread with the code that comes after await.
async void btn1_Click(object sender,EventArgs args)
{
var customerName=txtCustomer.Text;
var orders=await Task.Run(()=>LoadOrdersFromDbAsync(customerName));
grdOrders.DataSource=orders;
}

Thread killing by name

I have a problem with my thread...
Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, new ThreadStart(delegate {}));
Thread.Sleep(90);
It starts and works fine but like forever, and I don't want to run this thread forever.
Is there possible way to give to this thread a name so I can kill it by name in any time I want?
I tried kill it with:
Dispatcher.CurrentDispatcher.thread.Abort();
but it kill's whole app...
Basically...
I have a custom combo in my WPF app... this thread is in while loop, when I open the combo starts a loop while(!context.IsClosed) but when its closed, it still runs in background

Your understanding of multithreading approach is completely wrong.
First of all, no, there is no way to give a name to your thread being invoked in such way.
Second, killing a thread is a completely wrong approach in the situations like this, there is easy way to do such things: CancellationToken. You can use some overloads for the Dispatcher.Invoke with them (either using the start timeout or not), like this:
Dispatcher.Invoke Method (Action, DispatcherPriority, CancellationToken):
CancellationTokenSource s = new CancellationTokenSource();
Dispatcher.CurrentDispatcher.Invoke(() => YourMethodHere(), DispatcherPriority.Background, s.Token);
Thread.Sleep(90);
s.Cancel();
After calling the Cancel method the .NET will automatically stop your thread.
Second possible approach, as written in comments, is to use TPL for this, without using the Thread creation, something like this (code from MSDN article about SynchronizationContext):
// This TaskScheduler captures SynchronizationContext.Current.
TaskScheduler taskScheduler = TaskScheduler.FromCurrentSynchronizationContext();
// Start a new task (this uses the default TaskScheduler,
// so it will run on a ThreadPool thread).
Task.Factory.StartNew(() =>
{
// We are running on a ThreadPool thread here.
// Do some work.
// Report progress to the UI.
Task reportProgressTask = Task.Factory.StartNew(() =>
{
// We are running on the UI thread here.
// Update the UI with our progress.
},
s.Token,
TaskCreationOptions.None,
taskScheduler);
reportProgressTask.Wait();
// Do more work.
});

Task is being scheduled on the same thread as the caller's

My application has a View Model which contains a Lazy<BitmapImage> field. The field is populated using a service call to the server. In cases where the image is large, it takes a few seconds for the server to return the image (which is in fact a byte[]) therefore the UI is blocked. To prevent this, I put the service call in a Task, so that a background thread gets the image and then calls the OnPropertyChanged to let the UI know the image is returned:
Console.WriteLine("Outside Task ThreadID: {0}",
Thread.CurrentThread.ManagedThreadId);
Task.Factory.StartNew(() =>
{
Console.WriteLine("Inside Task ThreadID: {0}", Thread.CurrentThread.ManagedThreadId);
return Utilities.ConvertByteToImage(
SessionService.GetUserInformation(UserInfo.From).ProfilePicture);
}).ContinueWith(resultToken =>
{
m_lazyProfilePicture = new Lazy<BitmapImage>(() =>
{
return (resultToken.Result == null) ? Utilities.DefaultProfilePicture.Value : resultToken.Result;
});
OnPropertyChanged("ProfilePicture");
});
I noticed that even after putting the service call in a Task, the UI is till blocked. So added those Console.WriteLine lines to see the thread IDs. Surprisingly enough, both of them report the same thread ID (this seems to happen only in this case.I tried it with other tasks in the project, and they all report different IDs). Any idea what's going on here? Does it have anything to do with the BitmapImage? For some reason the scheduler decides to put the task in the same thread, but I don't understand why. Any suggestions are welcome!

StartNew doesn't ensure that the task is run in a new thread. It uses TaskScheduler.Current to schedule the new task. In many places throughout your code this will be null. When it is null, then TaskScheduler.Default will be used, which will schedule the delegate to run in the thread pool.
In your particular case Current is not null. It is the representation of some task scheduler that schedules the delegates to run in the UI thread.
One way this may have happened is if the code that you are running is the result of a call to StartNew or ContinueWith with the UI synchronization context. During the delegates executed in either case it will set the current scheduler to be one that is based on the SynchronizationContext provided, namely the UI context.
If you use Task.Run you avoid the issue; it will always use the default task scheduler instead of the current one.
Your other option is to explicitly state you want the default task scheduler:
Task.Factory.StartNew(() => { }
, CancellationToken.None
, TaskCreationOptions.None
, TaskScheduler.Default);

TaskScheduler.Current and TaskScheduler.FromCurrentSynchronizationContext() difference?

I have a task to get products from database, and the ContinueWith action that operate some UI modification, therefore I had a problem because the Task create a new thread, and the UI modification was executed not in the UI Thread.
I tried to use this fix :
var currentScheduler = TaskScheduler.Current;
Task.Factory.StartNew(() =>
{
// get products
}).ContinueWith((x) => handleProductsArrived(x.Result, x.Exception), currentScheduler);
but it didn't work at all. I check and the ContinueWith was not executed in the thread from currentScheduler but in an another.
I discovered this method :
Task.Factory.StartNew(() =>
{
// get products
}).ContinueWith((x) => handleProductsArrived(x.Result, x.Exception), TaskScheduler.FromCurrentSynchronizationContext());
and it works. So what's the differences? Why didn't my first code work?
Thanks!

From the documentation for TaskScheduler.Current:
When not called from within a task, Current will return the Default scheduler.
Then from the Task Schedulers documentation:
The default scheduler for Task Parallel Library and PLINQ uses the .NET Framework ThreadPool to queue and execute work.
So if you use TaskScheduler.Current when you're not in a task, you'll get a scheduler which uses the thread pool.
If you call TaskScheduler.FromCurrentSynchronizationContext(), you'll get one for the current synchronization context - which in Windows Forms or WPF (when called from a UI thread) is a context which schedules work on the relevant UI thread.
So that's why the first code didn't work: it executed your continuation on a thread pool thread. Your second code executed the continuation on the UI thread.
Note that if you can use C# 5 and async/await, all of this is handled much more simply.

Backgroundworker and TPL's Task have the same ManagedThreadID?

I have a Backgroundworker whose purpose is to run jobs sequentially in the background. Now one job is implemented in multithreading way. That mean, the Backgroundworker will create several threads. I use Task Parallel Library so I use the Task.Factory.StartNew to create multiple Tasks.
After the tasks are run, the Backgroundworker waits all of them to finish.
Now I print the Backgroundworker's ManagedThreadID and all the tasks' ManagedThreadIDs. I found that the BackgroundWorker's ManagedThreadID is always the same as the first task's ManagedThreadID. I think this shouldn't happen so I cannot explain. I think the Backgroundworker's thread must be different to all the tasks it creates so the ManagedThreadIDs must be all different from each other.
Can anyone explain why this scenario happens? Thank you very much.
Edit:
The code is similar to this:
Backgroundworker.Run(){
// Print Thread.CurrentThread.ManagedThreadID.
var task = Task.Factory.StartNew(action1); // action1, action2 also print ManagedThredID.
taskList.Add(task);
task = Task.Factory.StartNew(action2);
taskList.Add(task);
... // Several other tasks.
foreach(var task in taskList) task.Wait();
}
You will find that one task has the same ManagedThreadID as the Backgroundworker.

I would go on a limb here and guess that the TPL is smart enough to reuse the BackgroundWorker thread. Since the worker waits for all tasks to complete running one task in the same thread is probably an optimization.
From further investigation, what you are seeing is a result of the expected behaviour of the Task.Wait method. You can read more at Task.Wait and "Inlining" on the Parallel Programming Team blog.
If the Task being Wait’d on has
already started execution, Wait has to
block. However, if it hasn’t started
executing, Wait may be able to pull
the target task out of the scheduler
to which it was queued and execute it
inline on the current thread.

The Background worker draws threads from the thread pool as well as TPL. What might happen is that the background worker is started, it draws a thread from the pool and fires TPL threads and returns immediately the thread to the pool. By the time TPL's first task is executed TPL draws a thread from the pool and it happens that it picks the same thread as the one once used by the background worker.
Of course that's just a supposition which cannot be verified because you haven't shown your code.

What you have stumbled upon is of course not a problem but a feature (optimization): The TPL is re-using threads as much as it can.
When you create a Task it is not immediately/permanently associated with a Thread. A Task is a Job that is put in a Queue and the Queue(s) are serviced by worker threads. So it could be that the Bgw Task is suspended and its thread returned to the pool, or more directly it could be done by the Wait():
// thread A
var t1 = Task.Startnew(...);
var t2 = Task.Startnew(...);
t1.Wait(); // Thread A is idle/available so Wait can execute t1
t2.Wait();

Use TaskCreationOptions.LongRunning to avoid re-cycling the background worker.