I'm working on an application, and I'm using esri mechanisms for mapping services. I created a background thread, that loops through layers, executing spatial query on each layer to get back a list of features. but the background thread seems to block the UI thread for a couple of seconds and then start executing as required.
and the background thread periodically updates the UI thread.
I'm using background worker for this operation. thanks in advance
Related
Does JavaFX's AnimationTimer run on a separate thread when launched?
I ran a JavaFX application in a debugger, with and without a AnimationTimer, and in both cases there were 6 threads running. Plus, the JavaDocs don't mention it implementing Runnable.
That suggests that it's not run in its own thread, but by its very nature, I'd think it would need to run in its own thread to ensure it runs in a regular enough schedule.
And if it's not run in its own thread, is it just run in whatever thread creates it? Does that mean it's safe to modify UI elements from within the Timer if I create the AnimationTimer inside of Application's start()?
Does JavaFX's AnimationTimer run on a separate thread when launched?
No, it doesn't. It runs on the JavaFX application thread. The AnimationTimer's handle() method is called in every frame while the AnimationTimer is active. Normally, JavaFX tries to maintain a frame rate of 60 fps.
Does that mean it's safe to modify UI elements from within the Timer if I create the AnimationTimer inside of Application's start()?
Yes, it is. Since it runs on the JavaFX application thread, it is perfectly fine to modify scene graph elements. Just make sure you are not doing heavy computation in the handle().
I have a vb.net 4.0 UI that basically allows users to search for data on a SQL Server 2008 database and update/manipulate it. All of the communication with the database is done through stored procs. One of the update procs may take up to 6 minutes to process - currently the users just see the "processing..." message until the update has completed, and then they are shown the results.
I think this is a good candidate for a background task. I would like the users to be able to invoke the request, and then continue to do other work in the UI. When the task finishes it would notify them of the results. Can I accomplish this with threading? I'm new to threading but given some literature and an example or 2 I could be on my way. I've done some Googling but it's not apparent in the examples whether the user can continue working in the UI while the task executes. Are there other options to accomplish what I have described?
thanks.
There a number of options for running a background task, but in .net 4.0, the neatest is probably to make use of the TPL (Task Parallel Library). You can execute a background task as follows:
Task.Factory.StartNew(()=>SomeMethod());
Detail info can be found here.
http://msdn.microsoft.com/en-us/library/dd460717.aspx
Remember though, that if you need to perform any UI updates when returning from this call, you will need to dispatch that back on to the UI thread.
The TPL also has mechanism for running a continuation on the Dispatcher thread.
Whilst the background task is running, the UI thread will not be blocked.
I have a req where in i have to create a worker thread and keep it alive throughout my application life time to perform some back ground tasks . so is there any way i can stack tasks to this worker thread when ever needed by my application .?
Update: Even though you've indicated in comments you have to do this in Asp.Net, I'll leave my original content below, as it has some useful links.
Since Asp.Net uses the thread pool to schedule incoming requests, running your background task on the thread pool will take one thread off of it and will impact Asp.Net performance. Thus, you will have to use the Thread class.
To achieve your scenario, you can create a new Thread instance, set its IsBackground property to true and start it. Once started, the thread will wait for an AutoResetEvent (using the WaitOne method) to be set by an incoming request (using the Set met6hod), which will signal the background thread that its task should be processed. Once the task is finished, the background thread will again wait on the event.
This is the simplest implementation, which does not allow passing parameters between the request and the background thread and does not allow more than one tasks to be queued at a time. If you need support for parameters or queueing, you will have to keep a reference to the thread object somewhere it ill be accessible to the incoming requests.
You will also have to consider that your background thread can be killed at any point in time, if IIS decides to recycle the Asp.Net worker process. Also, throwing an exception inside the background thread will cause IIS to recycle the Asp.Net worker process.
There are also some considerations around the identity of the background thread. In particular, a background thread can't easily impersonate the identity of the user on the current incoming request. It is possible, but it will require you to pass the user identity each time a new task is scheduled by a request.
It would be useful if you tell us what language and what platform you are writing your code in.
If it happens to be a Windows platform, there is a thread pool you can "borrow" threads from for your tasks. You can schedule your task on the thread pool by using either the QueueUserWorkItem API (C++) or the ThreadPool.QueueUserWorkItem (C#/.Net). Note there are some implications if your task will be running for a longer time.
You can also create your own thread using either the Thread class (C#/.Net) or the _beginthreadex or the CreateThread API (C++). In this case, you will have to implement a queue for the foreground thread to schedule the tasks on and you will have a loop on the background thread to pick the new tasks and execute them. And of course, you will have to synchronize the access to that queue from both threads using some synchronization primitive like a CRITICAL_SECTION (C++) or the lock statement (C#/.Net).
For Linux or OS X you might look into POSIX threads. I have not done much *nix style programming, so there might be even better alternatives. If you are targeting one of these platforms, add that info to your question and I am sure there will be helpful answers in no time.
Creating a thread is typically done by calling a special primitive (CreateThread() in Win32) and passing it an entry function. That function code in invoked in the newly spawned thread and can do whatever it wishes - for example, it could start a loop and peek tasks from a queue created in advance. Your main thread could post tasks to that queue so that the worker thread processes them. When there're no tasks in the queue the worker thread could simply block on a synchronization primitive (an event for example) waiting for new tasks to be posted.
I was working on a project and there is bulk e-mail sending part of it and when user clicks on the button, he/she gets the "Thanks the e-mails have been sent" immediately as a Response and the same method is firing an async thread as well.
ThreadPool.QueueUserWorkItem(SendEMail, _message);
This thread is queued when user clicks on the send button but since this is default Background Thread I was expecting when the page response ended, this thread would be terminated but it didn't happen because the current thread which fires this Thread was also a Background Thread and a Worker Thread, so which means there is an unfinished foreground thread(s) (Could be MainThread or Worker Threads) still alive but I don't know when they finish because their finish time will effect my background worker threads; When the last foreground thread ends, it causes the process to be terminated, so do background threads.
Should I be afraid of this or Asp.NET can handle it automatically and I am kinda confused because I've read a lot of things about it and now everything is mixed up.
Could you please clarify things a little bit ?
Thanks in advance.
Using the ThreadPool for long-running tasks will negatively influence the performance of your application (because ASP.NET also uses the ThreadPool to handle incoming requests).
Creating threads manually for each task can also become a problem if too much threads are created.
One technique I've used in the past, is to create a custom ThreadPool when starting the application, and enqueuing tasks on that ThreadPool. A simple custom ThreadPool could consist of a single Thread and a Queue of tasks.
When you call QueueUserWorkItem a new thread will be drawn from the thread pool if available and execute the callback function on this thread. If no threads are available, the function will block until a thread is freed. Once it finishes the execution of the method the thread will be suspended and returned to the pool for further reuse. Your only concern should be the fact that threads from the pool are also used to service requests, so if you perform lengthy tasks on them you could jeopardize the whole system request servicing capabilities because there's a limited number of threads in the pool and if all of them are busy performing lengthy operations future HTTP requests will be queued. As an alternative you could consider creating threads manually: new Thread(state => { }).Start();
You can use MSMQ for creating your email queue and have a single thread process the queue.
The following post might be useful as it fits your problem domain. Although it does not use MSMQ but is a good post on processing scheduled tasks using ASP.net.
Simulate a Windows Service using ASP.NET to run scheduled jobs
I am getting started with ASP.NET web development and was wondering what the differences are when multi-threading a standard winforms application versus a web-based application written in asp.net that will run in IIS. Is there any difference and if so, what are the limitations (and conversely any positives) of threading a web application,
Thank you in advance
In the Windows GUI world, you always have the "UI thread" which you can use to communicate with the user. For example, you can start a BackgroundWorker in the UI thread, which will raise an event in the UI thread after completing its work: In a Windows UI application, you can be pretty sure that the UI thread is still there, unless the user has closed the application.
In the web world, you have no equivalent main thread. There are just web requests: Sometimes there are none and sometimes there are many at the same time; it is even possible that one single request will be handled by multiple threads without you knowing it. If you start a background thread with a lengthy operation, you need to either
delay finishing the web request until the background thread has completed -- which means a slow response time for the user and somehow defeats the purpose of a background thread or
regularly (during future requests) check the state of the thread and inform the user when it has finished.
Of course, that's only a problem if you want some user interaction after the thread has finished. If you don't, just start it and it will eventually finish (unless someone restarts IIS).
Threading isn't really an issue in the web world. There isn't any state and each request is a new instance of the web page. There are ways to track state between requests such as cookies, sessionstate, viewstate.